Blog

Cómo montar Distributed Statistics en Openx

Read this post in english

La gente de Openx tiene “Distributed Statistics” como opción para escalar el servicio, pero en mi opinión tienen la documentación un poco confusa, cuando no equivocada, como se puede ver en este mensaje que escribí yo mismo como “raistlink”.

El sistema de Distributed Statistics funciona así resumidamente (como yo lo he montado):

  • las dos máquinas sirven banners
  • sólo una de ellas (u otra adicional) además es el admin. A la que hace de admin la llamaré maestra y a la otra esclava.
  • sólo la máquina maestra ejecuta el maintenance que calcula las probabilidades de las zonas
  • la replicación hace que la esclava coja esas probabilidades
  • la esclava vuelca su actividad en el maestro ejecutando el maintenance-distributed en lugar del maintenance

Es fundamental que se configuren los crones de manera que cuando se ejecuta el maintenance de cada hora se haya volcado toda la actividad de la esclava porque si no esa actividad se perderá, por eso como veremos luego el maintenance en la maestra se ejecuta a las y cuarto y el maintenance-distributed en la esclava cada cinco minutos.

Pues bien, al final lo conseguí así que voy a explicar un poco lo que hice.

Partimos de dos máquinas independientes que están bajo un balanceador sirviendo banners bajo la misma url, por ejemplo my.adserver.com

En el maestro:

  • parar el apache
  • asegurarme de que no está el maintenance corriendo y quitar el cron
  • parar el mysql
  • poner en el my.conf
  • server-id = 1
    log-bin=mysql-bin

  • arrancar mysql
  • GRANT REPLICATION SLAVE ON *.* TO ’slave_user’@'%’ IDENTIFIED BY ‘XXXX’;
  • donde XXX es la contraseña con la que accederá el mysql esclavo para la replicación

  • GRANT ALL PRIVILEGES ON *.* TO ‘root’@'%’ IDENTIFIED BY ‘YYYY’;
  • donde YYYY es la contraseña con la que accederá el mysql esclavo para volcar sus estadísticas en el maestro.
    Ojo hay una contraseña para el la replicación y otra para volcar los datos desde el openx, no debería haber problema.

  • FLUSH PRIVILEGES;
  • hacer un show master status. ÉSTE ES EL QUE TENDRÉ QUE USAR LUEGO
  • mysql-bin.000001 | 417

  • hacer un dump
  • mysqldump -u root -p –databases openx_2_8_10 > /tmp/openx_2_8_10-201302071719.sql

  • arrancar apache
  • volver a hacer un show master status por curiosidad
  • mysql-bin.000001 | 24995895
    se ve que está replicando porque ha cambiado el número

En el esclavo:

  • eliminar base de datos de openx
  • volcar el dump del master
  • mysql -u root -pXXXX < "/tmp/openx_2_8_10-201302071719.sql"

  • ejecutar estos alter en la bbdd de datos del openx.
  • ALTER TABLE ox_data_raw_ad_click ENGINE=MyISAM;
    ALTER TABLE ox_data_raw_ad_impression ENGINE=MyISAM;
    ALTER TABLE ox_data_raw_ad_request ENGINE=MyISAM;
    ALTER TABLE ox_data_raw_tracker_impression ENGINE=MyISAM;
    ALTER TABLE ox_data_raw_tracker_variable_value ENGINE=MyISAM;
    Realmente yo estas tablas raw yo no he visto que se usen, pero bueno, a lo mejor sí y se purgan en seguida.

  • poner en el my.conf
  • server-id = 2
    log-bin=mysql-bin
    para que pudiera funcionar como maestro.
    replicate-wild-ignore-table=openx_2_8_10.%data_%
    replicate-wild-ignore-table=openx_2_8_10.%tmp_%
    replicate-wild-ignore-table=openx_2_8_10.%lb_local%
    replicate-wild-ignore-table=mysql.%
    replicate-wild-ignore-table=openx_2_8_10.%ox_log_maintenance_priority% (por un problema que tuve luego)
    replicate-wild-ignore-table=openx_2_8_10.%ox_session% (por un problema que tuve luego)

  • arrancar el mysql
  • comprobar si se puede acceder al mysql del maestro con esto
  • mysqldump –host=host_del_master -u root -pYYYY –databases openx_2_8_10 > /tmp/openx_2_8_10-201302080959.sql

  • STOP SLAVE;
  • CHANGE MASTER TO MASTER_HOST=’host_del_master’, MASTER_USER=’slave_user’, MASTER_PASSWORD=’XXXX’, MASTER_LOG_FILE=’mysql-bin.000001′, MASTER_LOG_POS=417;
  • (con los valores que dio en los pasos anteriores, ya están puestos)

  • START SLAVE;
  • SHOW SLAVE STATUS
  • Se ve que cada vez que lo ejecuto pone que va por un archivo diferente. Cuando ponga lo mismo que el show master status del maestro es que lo ha cogido ya todo. En muy poquito tiempo lo ha hecho.

Hasta aquí he configurado la replicación. Lo siguiente va a ser poner a funcionar el openx como delivery box en la esclava, es decir, que no funcione como admin y que vuelque su actividad (estadísticas) en el maestro.

En la maestra:

  • Si por ejemplo tu dominio es my.adserver.com crear un cname en el registrador de dominios para admin.my.adserver.com que apunte a la máquina maestra. Yo hice que la máquina maestra funcione como admin y sirviendo banners al mismo tiempo.
  • desactivar el automatic maintenance en el maestro desde el admin
  • configuration –> global settings –> Banner Delivery Settings –> “Admin Interface URL”
  • cambiar my.adserver.com por admin.my.adserver.com
    Él solo me redirije de la vieja a la nueva

  • cambiar el cron del maintenance en el maestro para que se ejecute a las y cuarto

En la esclava:

  • Hacer estos cambios en el conf de openx a mano
    1. poner el enabled del [ui] vacío
    2. poner el enabled del [lb] a 1
    3. en la sección [database] poner la bbdd local. (ya estaba)
    4. en la sección [lb] poner la bbdd maestra
    5. type=mysql
      host=host_del_master
      socket=
      port=3306
      username=root
      password=YYYY
      name=openx_2_8_10

    6. modificar el operationInterval en el esclavo para poder ejecutar el maintenance-distributed más a menudo, cada 5 min.
  • cambiar permisos al maintenance-distributed
  • chmod 777 [openx_home]/scripts/maintenance/maintenance-distributed.php

  • poner cron del maintenance-distributed cada 5 min

Para futuros esclavos se pueden seguir estas mismas intrucciones tal cual o generar un nuevo dump y poner el nuevo esclavo a “escuchar desde otro punto”, es decir, a un nuevo show master status.

Dejar una respuesta

Name (required)
Mail (will not be published) (required)

Your Comments: