seguridad:monitorizacion:zabbix3:ibdata1

Tabla de Contenidos

Problemas con la BDD de Zabbix

zabbix, mysql, mariadb, reparar, liberar, clean, recuperar

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

systemctl stop zabbix-server

y hacemos la copia

mysqldump -u user -p'lapassword' --single-transaction --quick nombrebasededatosacopiar | gzip > backup-nombrebasededatos-fecha.sql.gz

o si tenemos más bases de datos

mysqldump -u usuario -ptmppassword --all-databases > backup-fecha.sql

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

- Paramos el servidor de BDD

service mariadb stop

Borramos el archivo ibdata1 y sus logs

rm -rf /var/lib/mysql/ibdata1
rm -rf /var/lib/mysql/ib_logfile0
rm -rf /var/lib/mysql/ib_logfile1

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

 innodb_file_per_table=1

Iniciamos la BDD
```
service mariadb start
```

Borramos y volvemos a crear la base de datos

mysql -u user -p'lapassword' -e "drop database zabbix;"
mysql -u user -p'lapassword' -e "create database zabbix  character set utf8 collate utf8_bin;"

Le damos permisos al usuario

shell> mysql -uroot -p<password>
mysql> grant all privileges on zabbix.* to zabbix@localhost identified by '<password>';
mysql> quit;

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

gzip -d  backup-nombrebasededatos-fecha.sql.gz
mysql -u user -p'lapassword' nombrebasededatos <  backup-nombrebasededatos-fecha.sql

también podemos crearla nueva ejecutando

zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix

Iniciampos el servicio de zabbix
```
systemctl start zabbix-server
```

Referencias :

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

Si al ejecutar el comando

mysqlcheck --all-databases -p

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

mysqldump -u root -p mibdd tabla > bdd.tabla.sql

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

drop table bdd.table;

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.

 mysql -p bdd < bdd.table.sql

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.

yum install mysql-utilities

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

cp * /var/lib/mysql/zabbix/ /tmp/zabbix/

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:

mysqlq -p
mysql> use zabbix;
mysql> TRUNCATE TABLE history;
mysql> TRUNCATE TABLE history_str;
mysql> TRUNCATE TABLE history_uint;
mysql> TRUNCATE TABLE history_log;
mysql> TRUNCATE TABLE history_text;

Cerrar mysql y ejecutar

mysqlcheck -u root -p --auto-repair --check --all-databases

Borrar registros huérfanos

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