La mayoría de la gente que usa habitualmente Zabbix sabe el problema que éste tiene con la base de datos. Ya bien sea MySQL o cualquier otro motor. Una de las formas de evitar un acceso tan abusivo a los datos almacenados es dehabilitar el Housekeeping, o dicho de otra forma, deshabilitar el purgado de datos. Si hacemos esto, los datos almacenados en la base de datos nunca se borrarán y para evitar que crezcan sin control, la mejor solución es sin duda emplear un particionado de tablas.
Particionando las tablas conseguimos borrar de forma muy sencilla una gran cantidad de datos (partición == fichero en disco). Puesto que prácticamente todas las tablas dignas de ser particionadas en Zabbix tienen un campo llamado clock, de tipo unixtime, lo que facilita el particionado y el borrado.
En Zabbix 1.8, particionar las tablas y que todo funcionase no conllevaba problema alguno. Sin embargo con el upgrade a la 2.0 la cosa se complica. Si miramos un poco el schema de la base de datos podremos ver cosas como esta,
ALTER TABLE `screens` ADD CONSTRAINT `c_screens_1` FOREIGN KEY (`templateid`)... ALTER TABLE `media` ADD CONSTRAINT `c_media_1` FOREIGN KEY (`userid`)... ALTER TABLE `rights` ADD CONSTRAINT `c_rights_2` FOREIGN KEY (`id`)... ...
Estas reglas realizan una restricción de clave foránea, o dicho de forma más comprensible, un campo de una tabla influye directamente en la otra tabla. Por lo tanto, si borramos un valor de una de las tablas, este borrado se tiene que propagar al resto de tablas afectadas.
En la versión 2.0 de Zabbix este tipo de claves han aparecido y lo que en realidad es una facility muy interesante, en entornos de trabajo grandes puede ser un problema. Imaginemos el siguiente escenario en el que tenemos la tabla events está particionado por fecha (semana | mes) y que queremos comenzar a emplear las alertas para determinados eventos. Puesto que la tabla tiene creada la siguiente clave,
ALTER TABLE `alerts` ADD CONSTRAINT `c_alerts_2` FOREIGN KEY (`eventid`) REFERENCES `events` (`eventid`) ON DELETE CASCADE;
Cuando un nuevo evento intenta insertarse en la tabla alerts, tenemos el siguiente fallo,
[Z3005] query failed: [1452] Cannot add or update a child row: a foreign key constraint fails (`tiendas_produccion`.`alerts`, CONSTRAINT `c_alerts_2` FOREIGN KEY (`eventid`) REFERENCES `events` (`eventid`) ON DELETE CASCADE) [insert into alerts (alertid,actionid,eventid,userid,clock,mediatypeid,sendto,subject,message,status,alerttype,esc_step) values (9754,2,327497453,8,1362020524,1,'javier@domain.com','PROBLEM: Zabbix Agent fail','Trigger: Zabbix Agent fail Trigger status: PROBLEM Trigger severity: Information
Este fallo realmente es provocado por MySQL, que no soporta las claves "CONSTRAINT FOREIGN KEY" contra tablas particionadas. Si se piensa fríamente, tiene lógica ya que si se borra una partición, el motor de base de datos no puede controlar la clave. Esto pasará con cualquier tabla, pero en lo que nos afecta a nosotros es para Zabbix, en su versión 2.0.
Entonces, ¿cómo lo solucionamos?
Pues bien, como sabemos cual es el problema (la clave foránea) y como tenemos controlado el crecimiento de nuestras tablas con particiones y no nos interesa la funcionalidad que ofrecen estas claves (no las podemos usar), la mejor solución es sin duda, borrar las claves que no se usan. Así que vamos allá!
mysql> ALTER TABLE events DROP FOREIGN KEY c_alerts_2; ERROR 1506 (HY000): Foreign key clause is not yet supported in conjunction with partitioning
Justamente queremos borrar la clave y nos da un error de que no se puede hacer, justamente por tener la tabla particionada. No pasa nada, no hay nada que root no sea capaz de hacer. Para ello vamos a optar por deshabilitar las claves foráneas,
mysql> SET FOREIGN_KEY_CHECKS = 0; Query OK, 0 rows affected (0.00 sec) mysql> flush privileges; Query OK, 0 rows affected (0.00 sec)Y lo volvemos a intentar,
mysql> ALTER TABLE alerts DROP FOREIGN KEY c_alerts_2;Esta vez ya sin problemas lo pudo ejecutar y las alertas ya comenzarán a funcionar sin problemas en Zabbix.
La entrada Zabbix + MySQL + CONSTRAINT FOREIGN KEY la puedes leer en Puppet Linux.
No hay comentarios :
Publicar un comentario