meta data de esta página
  •  

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anteriorRevisión previa
Próxima revisión		Revisión previa
seguridad:monitorizacion:zabbix3:ibdata1 [2018/02/23 10:16] – lcseguridad:monitorizacion:zabbix3:ibdata1 [2023/01/18 14:46] (actual) – editor externo 127.0.0.1
Línea 1: Línea 1:
 {{tag> zabbix mysql mariadb reparar liberar clean recuperar}} {{tag> zabbix mysql mariadb reparar liberar clean recuperar}}
-===== Liberar espacio o reparar la base de datos de Zabbix ===== +===== Problemas con la BDD de Zabbix ===== 
-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 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+==== 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
  
-La solución a dicho problema es el siguiente : +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.
-  * Paramos el servicio de zabbix <sxh>systemctl stop zabbix-server</sxh> +
-  *  Editamos el fichero /etc/my.cnf y añadimos la siguiente líenea bajo la sección [mysqld] +
-<sxh> innodb_file_per_table=1 </sxh> +
-  * Reiniciamos la  BDD <sxh>systemctl restart mariadb</sxh> +
-  * Hacemos una copia de todas las Bases de datos <sxh>mysqldump -u root -ptmppassword --all-databases > dump.sql</sxh> +
-  * También deberíamos de hacer una copia de los ficheros existentes dentro de **/var/lib/mysql** +
-   * Nos conectamos al mysql y borramos la Base de datos zabbix<sxh>mysql>drop database zabbix;</sxh>  +
-<note>No borrar el resto de BDD</note> +
- * Salimos de la base de datos y paramos el servicio <sxh>systemctl stop mariadb</sxh> +
-  * Borramos los ficheros ibdata1 y los ficheros  ib_logfile*  +
-<sxh>cd /var/lib/mysql/ +
-rm ibdata1 +
-rm ib_logfile* +
-</sxh> +
-  *  Iniciamos el servicio de BDD y volvemos a crear la base de datos zabbix +
-<sxh>   +
-systemctl start mariadb +
-mysql -u root -p</sxh> +
-Una vez conectados a MySQL creamos una nueva base de datos llamada zabbix +
-<sxh>mysqld>    CREATE DATABASE zabbix;</sxh>+
  
-Una vez que nos sale el mensaje de que la operación se ha efectuado  +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. 
-<code> + 
-Output +Yo he optado por el segundo método, para ello he seguido estos pasos: 
-Query OK, 1 row affected (0.00 sec) + 
-</code> +  * Lo primero es tener una copia de seguridad de la base de datos  
-Salimos de MySQL con CTRL+D. y desde la línea de comando ejecutamos el siguiente comando para importar la copia que había creado: +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> 
-<sxh>mysql -u root -p zabbix < dump.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>   * 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 ==== ==== Reparar error mysql ‘table’ doesn’t exist in engine ====
-si nos aparece este error y no podemos hacer un copia de seguridad de nuestra BDD,  debemos de ir a la ubicación de nuestra base de datos /var/lib/mysql/zabbix y renombrar o borrar todos los ficheros con extensión **frm** que aparecen.+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 
 + 
 + 
 + 
 +  
  
-<note>es preferible renombrar los ficheros, ya que desde dichos ficheros frm también es posible recuperar la BDD con el siguiente proceso http://www.juanmitaboada.com/recuperar-una-tabla-de-mysql-desde-los-ficheros-frm-y-ibd/</note> 
  
 ==== Solucionar problemas de corrupción ==== ==== 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: 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>mysqlq -p +<sxh sql>mysqlq -p 
-mysql> use zabbix; +mysql> use zabbix;
 mysql> TRUNCATE TABLE history; mysql> TRUNCATE TABLE history;
 mysql> TRUNCATE TABLE history_str; mysql> TRUNCATE TABLE history_str;
Línea 52: Línea 101:
 Cerrar mysql y ejecutar <sxh>mysqlcheck -u root -p --auto-repair --check --all-databases</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 
  
-The issue seems to be around the history_uint table becoming too big or corrupt. 
  
 ==== Referencias ==== ==== Referencias ====
   * http://www.thegeekstuff.com/2016/02/mysql-innodb-file-per-table/   * http://www.thegeekstuff.com/2016/02/mysql-innodb-file-per-table/
   * http://www.michaelfoster82.co.uk/zabbbix-database-is-down/   * 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/