主 Openx 服务器不处理从属统计信息
OpenX 信息：OpenX v2.8.7 在 Apache 2.2.19、PHP 5.3.6 和 MySQL 5.1.56-log 下运行。
我在分布式 OpenX 安装时遇到一些问题。
我的架构基于一台具有全局数据库和管理界面的主服务器，以及一些具有为横幅提供服务的本地数据库的从服务器（目前是一台）。
主服务器的 MySQL 复制工作正常（因为主服务器中的每个更改都会复制到从服务器上），并且维护脚本（主服务器的 maintenance.php 和从服务器的 Maintenance-distributed.php）看起来运行良好（没有错误的调试痕迹）。该系统是按照分布式系统的 OpenX 文档进行配置的。
这些是运行维护脚本的 cronjobs：
MASTER
5 * * * * /usr/local/bin/php /var/www/scripts/maintenance/maintenance.php www.mydomine.com
SLAVE
10,25,40,55 * * * * /usr/local/bin/php /var/www/scripts/maintenance/maintenance-distributed.php www.mydomine.php
问题是印象摘要没有被计算并显示在管理界面（在 MASTER 服务器上），我一直在调试，最终得到下一个结果：
- 横幅 正在 正在提供服务 正常
- 从属服务器正在 记录展示次数 正常
- 从属服务器正在< /strong> 将数据发送回 MASTER OK
- 主站正在从服务器获取数据（表 ox_data_bkt_* 已满）
- 主服务器未在管理界面上汇总数据
这是来自 MASTER 数据库的示例查询：
select interval_start, sum(count) from ox_data_bkt_m group by interval_start;
结果包含从从设备记录并发送到主设备的所有展示次数。
+---------------------+------------+
| interval_start | sum(count) |
+---------------------+------------+
| 2011-06-25 10:00:00 | 1883133 |
| 2011-06-25 11:00:00 | 2074979 |
| 2011-06-25 12:00:00 | 2239609 |
+---------------------+------------+
5 rows in set (0.00 sec)
但在管理界面上，我当时没有任何印象......
尝试一些东西，我们意识到脚本 scripts/maintenance/tool/republish.php 实际上解决了过去统计数据的问题，但是新的仍然没有出现。我们发现，在 MASTER 上的每个维护周期后使用 republish.php 脚本将获得正确的数字，但我认为这是一个肮脏的修复，并且必须是一个真正的解决方案。
OpenX info: OpenX v2.8.7 running under Apache 2.2.19, PHP 5.3.6 and MySQL 5.1.56-log.
I'm having some troubles with a distributed OpenX installation.
I have an architecture based on one MASTER server with global database and administration interface and some SLAVE servers (for now one) with a local database that serve the banners.
The MySQL replication of the MASTER is working fine (as every change in the master is replicated onto the slave) and the maintenance scripts (maintenance.php for the MASTER and maintenance-distributed.php for the SLAVE) look like are working well (no bad debug traces). The system was configured following the OpenX documentation for distributed systems.
These are the cronjobs that runs the maintenance scripts:
MASTER
5 * * * * /usr/local/bin/php /var/www/scripts/maintenance/maintenance.php www.mydomine.com
SLAVE
10,25,40,55 * * * * /usr/local/bin/php /var/www/scripts/maintenance/maintenance-distributed.php www.mydomine.php
The problem is that the impression summary are not being calculated and showed on the admin interface (on the MASTER server), I've been debugging and I end up with the next result:
- The banners are being served OK
- The slave server is logging the impressions OK
- The slave server is sending the data back to the MASTER OK
- The master is getting the data from the server (the tables ox_data_bkt_* are full)
- The master is not summarizing the data on the administration interface
This is a example query from the MASTER database:
select interval_start, sum(count) from ox_data_bkt_m group by interval_start;
The result contains all the impressions logged and sended from the SLAVE to the MASTER.
+---------------------+------------+
| interval_start | sum(count) |
+---------------------+------------+
| 2011-06-25 10:00:00 | 1883133 |
| 2011-06-25 11:00:00 | 2074979 |
| 2011-06-25 12:00:00 | 2239609 |
+---------------------+------------+
5 rows in set (0.00 sec)
But on the administration interface I got no impressions for that times....
Trying things we realized that the script scripts/maintenance/tool/republish.php actually fix the problem for the past stats, but the new ones still doesn't show up. We figure out that using the republish.php script after every maintenance cycle on the MASTER will get the right numbers, but i think this is a dirty fix and must be a real solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我见过这种情况的几乎所有情况下，事实证明主设备和从设备上的时钟在不同的时区设置下运行，导致主设备寻找根本不存在的原始统计数据。
In almost all cases where I've seen this happening, it turned out the clocks on the master and on the slave were running at different time zone settings, causing the master to look for raw stats that simply weren't there (yet).
问题已解决，这是维护脚本的时间安排问题。
在主节点上调用maintenance.php之前，必须在从属节点上调用maintenance-distributed.php，但是一旦最后一小时的统计数据已经消失，就必须调用maintenance-distributed.php...只是一个举例说明：
我从 00:00:00 到 00:59:59 在从属服务器中获得印象，我在 01:01:00 在从属服务器上运行maintenance-distributed.php 和数据被发送回 MASTER 节点，现在，例如在 01:05:00 我可以在 MASTER 节点上运行maintenance.php。
这些是新的 cronjobs：
MASTER
SLAVE
The problem is fixed, it was a problem with the timing of the maintenance scripts.
The maintenance-distributed.php have to be called on the slave nodes BEFORE the maintenance.php is called on the MASTER node, BUT maintenance-distributed.php have to be called once the last hour of statistics is already gone... just an example to make it clear:
I get impressions in the slave server from 00:00:00 to 00:59:59 the I run maintenance-distributed.php at 01:01:00 on the slave server and the data are sent back to the MASTER node, now, say for example at 01:05:00 I can run maintenance.php on the MASTER node.
These are the new cronjobs:
MASTER
SLAVE