Si usas Zabbix, especialmente a gran escala o en discos más lentos, sabrás que uno de los principales procesos que más consumen es el de housekeeping. Este proceso se encarga de "limpiar" los datos que sobran y crear las tendencias de los item's para así poder borrar datos de la base de datos. Con él se pierden datos "brutos" y genera tendencias. Este proceso es muy costoso, pues saca los datos de la tabla history, los procesa y los vuelve a insertar en la tabla trends (a groso modo).
Si lo que deseamos es aumentar en rendimiento, la solución ideal es deshabilitarlo en el fichero de configuración (/etc/zabbix/zabbix_server.conf).
... ### Option: DisableHousekeeping # If set to 1, disables housekeeping DisableHousekeeping=1 ...
pero esto conlleva un problema que no es otro que el crecimiento de todos los datos de la base de datos. Sin un proceso que borre, los datos estarán ahí para siempre. La solución a este problema es el particionado de las tablas. En vez de dejar el proceso de purgado de datos a un proceso externo, mejor gestionarlo desde el propio MySQL. Para ello, únicamente llega con crear particiones por día/semana/mes (según la carga de datos que tengas) e irlas borrando según los datos ya no te interesen. Así de una forma muy sencilla podrás eliminar todos los datos de todos los host's de un día/semana/mes.
Un día escribiré un post sobre este tema, pero hoy vamos a lo que nos atañe, que no es otra cosa que un problema en la versión 2.0 de Zabbix a la hora de crear las particiones. Generalmente las tablas afectadas de particionado son las de events y las de history* y hasta la versión 2.0 no había ningún problema. En esta nueva versión, al crear las particiones para la tabla events, obtenemos el siguiente error:
mysql> ALTER TABLE events -> PARTITION BY RANGE (clock) ( -> PARTITION p50 VALUES LESS THAN (1355698800), -> PARTITION p51 VALUES LESS THAN (1356303600) -> ); ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails
Sin embargo, dicha tabla si la observáis (SHOW CREATE TABLE events) no presenta ninguna clave foránea, como indica, pero sin embargo no deja crear las particiones que necesitamos.
Ventajas del software libre, podemos observar el schema que Zabbix crea en MySQL y las relaciones que la tabla events tiene, observando que el campo eventid sí es una clave foránea de las tablas alerts y acknowledges.
Para poder particionar las tablas entonces, necesitamos borrarlas.
mysql> ALTER TABLE alerts DROP FOREIGN KEY c_alerts_2; mysql> ALTER TABLE acknowledges DROP FOREIGN KEY c_acknowledges_2;
Ahora ya se nos permitirá crear las nuevas particiones que nos interesan en la tabla events,
mysql> ALTER TABLE events -> PARTITION BY RANGE (clock) ( -> PARTITION p50 VALUES LESS THAN (1355698800), -> PARTITION p51 VALUES LESS THAN (1356303600) -> );
Y puesto que nos interesa seguir manteniendo todas las funcionalidades de Zabbix a nivel de base de datos, creamos nuevamente las claves foráneas que anteriormente habíamos borrado.
mysql> ALTER TABLE `alerts` -> ADD CONSTRAINT `c_alerts_2` -> FOREIGN KEY (`eventid`) -> REFERENCES `events` (`eventid`) ON DELETE CASCADE; mysql> ALTER TABLE `acknowledges` -> ADD CONSTRAINT `c_acknowledges_2` -> FOREIGN KEY (`eventid`) -> REFERENCES `events` (`eventid`) ON DELETE CASCADE;Actualización: Quizás antes de volver a crear estas claves te interese leer esto, puesto que a la larga puede traer problemas en el envío de alertas.
No hay comentarios :
Publicar un comentario