Главный сервер Openx не обрабатывает подчиненную статистику - PullRequest
Новая
       27

Главный сервер Openx не обрабатывает подчиненную статистику

2 голосов
/ 25 июня 2011

Информация об OpenX: OpenX v2.8.7, работающий под Apache 2.2.19, PHP 5.3.6 и MySQL 5.1.56-log.

У меня проблемы с распределенной установкой OpenX.

У меня есть архитектура, основанная на одном сервере MASTER с глобальной базой данных и интерфейсом администрирования, а также на некоторых SLAVE-серверах (на данный момент один) с локальной базой данных, обслуживающей баннеры.

Репликация MySQL MASTER работает нормально (так как каждое изменение в мастере реплицируется на ведомое устройство), и сценарии обслуживания (maintenance.php для MASTER и maintenance-distrib.php для SLAVE) работают хорошо (нет плохих следов отладки). Система была настроена в соответствии с документацией 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), я отлаживаю и получаю следующий результат:

  1. Баннеры обслуживаются ОК
  2. подчиненный сервер - регистрация показов OK
  3. подчиненный сервер является отправкой данных обратно на MASTER OK
  4. Мастер - это получение данных с сервера (таблицы ox_data_bkt_ * заполнены)
  5. Мастер не суммирует данные в интерфейсе администрирования

Это пример запроса из базы данных 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 на самом деле решает проблему с прошлой статистикой, но новые по-прежнему не отображаются. Мы выяснили, что использование сценария republish.php после каждого цикла обслуживания на MASTER даст правильные цифры, но я думаю, что это грязное исправление и должно быть реальным решением.

Ответы [ 2 ]

4 голосов
/ 27 июня 2011

Почти во всех случаях, когда я видел это, оказалось, что часы на ведущем и ведомом устройстве работают с разными настройками часового пояса, в результате чего ведущее устройство ищет необработанную статистику, которой просто не было ( пока).

1 голос
/ 27 июня 2011

Проблема исправлена, это была проблема с синхронизацией сценариев обслуживания.

Файл обслуживания-distrib.php должен вызываться на подчиненных узлах ДО ТОГО, как файл обслуживания.php вызывается на MASTER.узел, НО техобслуживание-распределенный.php должен быть вызван, как только последний час статистики уже прошел ... просто пример, чтобы прояснить это:

Я получаю показы на подчиненном сервере с 00:00:С 00 до 00:59:59 я запускаю maintenance-distrib.php в 01:01:00 на подчиненном сервере, и данные отправляются обратно на узел MASTER, теперь, например, в 01:05:00 я могу запуститьmaintenance.php на узле MASTER.

Это новые cronjobs:

MASTER 

5 * * * * /usr/local/bin/php /var/www/scripts/maintenance/maintenance.php www.mydomine.com

SLAVE 

1,10,25,40,55 * * * * /usr/local/bin/php /var/www/scripts/maintenance/maintenance-distributed.php www.mydomine.php
...