Problemas con la BDD de Zabbix

Liberar espacio

Revisar las configuración del parámetro HouseKeeping

Fichero ibdata muy grande

A veces en instalaciones de zabbix que llevan un tiempo en funcionamiento y que se han ido actualizando nos econtramos que el fichero ibdata1 es de un tamaño enorme. Eso es debido a que en MySQL cuando usamos el motor de bases de datos InnoDB, todas las tablas e indices se almacenan bajo la tabla system de MySQL, que se corresponde con el fichero ibdata1, que se encuentra en la carpeta /var/lib/mysql

Para colmo de males cuando se elimina una tabla o toda una base de datos, el espacio que ocupaban en el fichero ibdata1 no se recupera.

La solución a dicho problema podemos hacer dos cosas: cambiar el motor de bases de datos a MyISAM o bien realizar un volcado completo de todas las bases de datos, reiniciar el servidor y recuperar el volcado y reconfigurar el servidor para que las tablas innodb se almacenen en ficheros independientes, evitando de este modo que vuelva a aparecer el problema.

Yo he optado por el segundo método, para ello he seguido estos pasos:

Lo primero es tener una copia de seguridad de la base de datos

Paramos el servidor de zabbix y hacemos la copia o si tenemos más bases de datos

tampoco está de más hacer una copia de los ficheros existentes dentro de /var/lib/mysql

- Paramos el servidor de BDD

Borramos el archivo ibdata1 y sus logs

Editamos el fichero /etc/my.cnf y añadimos la siguiente línea bajo la sección [mysqld]

Iniciamos la BDD

Borramos y volvemos a crear la base de datos

Le damos permisos al usuario

Salimos de MySQL y desde la línea de comando ejecutamos el siguiente comando para importar la copia que había creado:

también podemos crearla nueva ejecutando

Iniciampos el servicio de zabbix

Referencias :

https://blog.openalfa.com/como-reducir-el-tamano-del-fichero-ibdata1-en-mysql

https://mierda.tv/2017/06/19/solucion-a-archivo-ibdata1-gigante-con-mysql/

Reparar error mysql ‘table’ doesn’t exist in engine

Si al ejecutar el comando y nos aparece errores del tipo Table 'nombre_tabla' doesn't exist in engine, indica que tenemos nuestra base de datos corrupta. Podemos solucionar el problema si tenemos una copia con mysqldump ya que podríamos reintalar los datos, o en caso de no tener copia probar con una recuperación automática, pero en caso contrario vamos a tener que recuperar la misma desde los ficheros ibd y frm.

Intentar la recuperación automática

Lo primero intenta hacer una copia de los ficheros de la bdd (/var/lib/mysql/) o un snapshot de la máquina por si hay problemas

Podemos instentar usar la opción innodb_force_recovery= para recuperar nuestra bdd. a este parámetro le damos un valor entre 0 y 6. Un valor mayor también incluye las comprobaciones de los valores anteriores, es decir si ponemos el 4 estamos incluyendo las comprobaciones de los niveles 1,2 y3 también.

el valor 0 es el valor por defecto que no realiza recuperación. Los valores entre 1 y 3 son más seguros y se pierden menos datos Los valores entre 4 y 6 son más peligrosos y se pueden perder más datos.

Para forzar la recuperación de nuestra bdd editamos my.cnf, añadimos innodb_force_recovery=1 y reiniciamos mysql.

Revisar los logs de mysql . En caso de que salga un aviso del tipo “InnoDB: Waiting for the background threads to start” entonces además hay que añadir al my.cnf la siguiente opción innodb_purge_threads=0

Intentamos ver si podemos hacer un volcado de la bdd tabla por tabla Si no podemos, repetimos el proceso aumentanto el valor del parámetro innodb_force_recovery y repetimos

El siguiente paso una vez que hemos podido hacer el volcado es borrar la/s tablas corruptas

Quitamos las opciones que añadimos al fichero my.cnf y reiniciamos mysql

Como paso final importamos cada tabla que habíamos volcado a la copia.

Recuperación mediante los ficheros y frm

Los ficheros ibd contienen los datos y los ficheros frm la estructura .

Lo primero de todo es que vamos a necesitar es instalar el paquete mysql-utilities para poder usar la herramienta mysqlfrm.

Copiamos todos los ficheros de mi BDD a una nueva localización.

el nombre del directorio donde copiamos los ficheros bdd tiene que ser el mismo que tenía la BDD original, en mi caso zabbix

Lanzamos desde la ubicación de la copia una nueva instancia de la BDD pero es muy importante que sea en otro puerto distinto y que mysql tengas permisos de escritura en la carpeta ya que no podemos levantar dos instancias como root

cd /tmp/ mysqlfrm –user=mysql –server=root:contraseña@localhost –port=3307 /tmp/copiabdd/ > tmp/crear-tablas.sql

Solucionar problemas de corrupción

Si tenemos problemas de que la base de datos de zabbix se queda incoherente, normalmente será porque la tabla history_uint es muy grande o está corrupta. Para solucionarlo podemos hacer lo siguiente:

Cerrar mysql y ejecutar

Borrar registros huérfanos

https://github.com/mattiasgeniar/zabbix-orphaned-data-cleanup

Referencias

http://www.thegeekstuff.com/2016/02/mysql-innodb-file-per-table/

http://www.michaelfoster82.co.uk/zabbbix-database-is-down/

https://www.zabbix.com/documentation/3.4/manual/appendix/install/db_scripts#mysql

https://www.claudiokuenzler.com/blog/752/recover-crashed-mysql-mariadb-innodb-database-from-ibd-files#.WoFTw-cWW73

http://blackbird.si/mysql-corrupted-innodb-tables-recovery-step-by-step-guide/

https://chepri.com/blog/mysql-innodb-corruption-and-recovery/

http://www.juanmitaboada.com/recuperar-una-tabla-de-mysql-desde-los-ficheros-frm-y-ibd/

http://www.sohailriaz.com/recover-innodb-tables-using-frm-and-ibd-files/

https://www.claudiokuenzler.com/blog/752/recover-crashed-mysql-mariadb-innodb-database-from-ibd-files#.Wo_8KucWW73

https://www.thegeekstuff.com/2014/04/recover-innodb-mysql/