{{tag> zabbix mysql mariadb reparar liberar clean recuperar}}
===== Problemas con la BDD de Zabbix =====
==== Liberar espacio ====
Revisar las configuración del parámetro [[seguridad:monitorizacion:zabbix3:housekeeping|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 <sxh>systemctl stop zabbix-server</sxh> y hacemos la copia <sxh>mysqldump -u user -p'lapassword' --single-transaction --quick nombrebasededatosacopiar | gzip > backup-nombrebasededatos-fecha.sql.gz</sxh> o si tenemos más bases de datos   <sxh>mysqldump -u usuario -ptmppassword --all-databases > backup-fecha.sql</sxh>
<note>tampoco está de más hacer una copia de los ficheros existentes dentro de **/var/lib/mysql**</note>
 - Paramos el servidor de BDD <sxh>service mariadb stop</sxh>
  * Borramos el archivo ibdata1 y sus logs <sxh>rm -rf /var/lib/mysql/ibdata1
rm -rf /var/lib/mysql/ib_logfile0
rm -rf /var/lib/mysql/ib_logfile1</sxh>
  * Editamos el fichero /etc/my.cnf y añadimos la siguiente línea bajo la sección [mysqld]
<sxh> innodb_file_per_table=1 </sxh>
  * Iniciamos la  BDD <sxh>service mariadb start</sxh>
  * Borramos y volvemos a crear la base de datos <sxh>mysql -u user -p'lapassword' -e "drop database zabbix;"
mysql -u user -p'lapassword' -e "create database zabbix  character set utf8 collate utf8_bin;"</sxh>
  * Le damos permisos al usuario <sxh>shell> mysql -uroot -p<password>
mysql> grant all privileges on zabbix.* to zabbix@localhost identified by '<password>';
mysql> quit;</sxh>
  * Salimos de MySQL y desde la línea de comando ejecutamos el siguiente comando para importar la copia que había creado:
<sxh>gzip -d  backup-nombrebasededatos-fecha.sql.gz
mysql -u user -p'lapassword' nombrebasededatos <  backup-nombrebasededatos-fecha.sql
</sxh><note>también podemos crearla nueva ejecutando <code>zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix</code></note>
  * Iniciampos el servicio de zabbix <sxh>systemctl start zabbix-server</sxh>

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 <sxh>mysqlcheck --all-databases -p</sxh> 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 ===
<note warning>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 </note>
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. 

<note>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** </note>

Intentamos ver si podemos hacer un volcado de la bdd tabla por tabla <sxh>mysqldump -u root -p mibdd tabla > bdd.tabla.sql</sxh>  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 <sxh>drop table bdd.table;</sxh>

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. <sxh> mysql -p bdd < bdd.table.sql</sxh>


=== 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.

<sxh>yum install mysql-utilities</sxh>

Copiamos todos los ficheros de mi BDD a una nueva localización. <sxh>cp * /var/lib/mysql/zabbix/ /tmp/zabbix/</sxh>
<note>el nombre del directorio donde copiamos los ficheros bdd tiene que ser el mismo que tenía la BDD original, en mi caso zabbix</note>

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:

<sxh sql>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;
</sxh>
Cerrar mysql y ejecutar <sxh>mysqlcheck -u root -p --auto-repair --check --all-databases</sxh>

==== 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/