Problemas en BD

[David_Carrera_G]

Estimados, me dirijo a ustedes por un problema que tengo en el servidor de la base de datos, esto paso de noche y nadie vio que fue lo que sucedió, solo tengo las siguientes evidencia del problema, acudo a ustedes en busca de ayuda, porque ne realidad no puedo determinar que fue lo que gatillo este problema. Saludos

PRINT de error al iniciar el MYSQL en XAMP



LOG del error que dio:

Código BASH:

2015-02-11 21:19:49 2868 [Note] Plugin 'FEDERATED' is disabled.
2015-02-11 21:19:49 2868 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-02-11 21:19:49 2868 [Note] InnoDB: The InnoDB memory heap is disabled
2015-02-11 21:19:49 2868 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2015-02-11 21:19:49 2868 [Note] InnoDB: Memory barrier is not used
2015-02-11 21:19:49 2868 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-02-11 21:19:49 2868 [Note] InnoDB: Not using CPU crc32 instructions
2015-02-11 21:19:49 2868 [Note] InnoDB: Initializing buffer pool, size = 1.0G
2015-02-11 21:19:49 2868 [Note] InnoDB: Completed initialization of buffer pool
2015-02-11 21:19:49 2868 [Note] InnoDB: Highest supported file format is Barracuda.
2015-02-11 21:19:49 2868 [Note] InnoDB: The log sequence numbers 40182862502 and 40182862502 in ibdata files do not match the log sequence number 82832948933 in the ib_logfiles!
2015-02-11 21:19:49 2868 [Note] InnoDB: Database was not shutdown normally!
2015-02-11 21:19:49 2868 [Note] InnoDB: Starting crash recovery.
2015-02-11 21:19:49 2868 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-02-11 21:19:51 2868 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace db_dtv/basetodoslosclientes_paso uses space ID: 2 at filepath: .\db_dtv\basetodoslosclientes_paso.ibd. Cannot open tablespace mysql/innodb_index_stats which uses space ID: 2 at filepath: .\mysql\innodb_index_stats.ibd
InnoDB: Error: could not open single-table tablespace file .\mysql\innodb_index_stats.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
 

[gnzsoloyo]

La respuesta te la está dando el mismo MySQL:

We do not continue the crash recovery, because the table may become corrupt if we cannot apply the log records in the InnoDB log to it.
To fix the problem and start mysqld:
1) If there is a permission problem in the file and mysqld cannot open the file, you should modify the permissions.
2) If the table is not needed, or you can restore it from a backup, then you can remove the .ibd file, and InnoDB will do a normal crash recovery and ignore that table.
3) If the file system or the disk is broken, and you cannot remove the .ibd file, you can set innodb_force_recovery > 0 in my.cnf and force InnoDB to continue crash recovery here.

A groso modo:

No se puede seguir la recuperación de una caída, ya que la tabla puede corromperse si no se puede aplicar los registros de log en el registro de InnoDB de la misma.
Para solucionar el problema e iniciar mysqld:
1) Si hay un problema de permisos en el archivo y mysqld no puede abrir el archivo, debe modificar los permisos.
2) Si no se necesita la tabla, o se puede restaurar desde una copia de seguridad, a continuación, puede eliminar el archivo .ibd y InnoDB va a hacer una recuperación normal del incidente e ignorar esa tabla.
3) Si el sistema de archivos o el disco se rompe, y no se puede quitar el archivo .ibd, puede establecer innodb_force_recovery> 0 en my.cnf y forzar InnoDB para continuar la recuperación de bloqueo.

Obviamente ha habido un problema catastrófico, que usualmente se recupera con una buena politica de backups... que probablemente no haya sido llevada adelante, si se cumple la Ley de Murphy.

[David_Carrera_G]

Que tal gnzsoloyo si bien en el LOG mencionaba claramente que el problema se llevo a cabo por que se corrompió algún archivo, este no fue el problema de raíz que nos puso de cabeza en el trabajo, el problema según lo que logramos analizar se genero gracias al llenado de los archivos .IBD y .FRM, estos archivos fueron llenados casi sobrepasando su limite y todo gracias a un proceso que existía desde el año 2008 el cual ejecutaba un PHP que no tenia autor... El problema aún esta en análisis pero ahora por parte de los encargados de IT, cuando tenga ya el diagnostico completo, lo compartiré por acá, porque creo que es bueno saber los pequeños BUG que se pueden ir generando al no realizar limpieza en nuestras aplicaciones o bases de datos.