Tablas MySQL faltantes/dañadas después de la recreación

Question

Ayer volqué mis bases de datos MySQL a un archivo SQL y cambié el nombre del archivo ibdata1. Luego lo recreé, importé el archivo SQL y moví el nuevo archivo ibdata1 a mi directorio de datos MySQL, eliminando el anterior.

Lo he hecho antes sin problemas, pero esta vez algo no está bien. Cuando examino las bases de datos (personales, no de configuración MySQL), están todas ahí, pero están vacías... más o menos. El directorio de datos todavía tiene los archivos .ibd con el contenido correcto y puedo ver la tabla.listaen las bases de datos, pero no en las tablas mismas. (Tengo habilitado el archivo por tabla y estoy usando InnoDB como predeterminado para todo).

Por ejemplo con elURLbase de datos y susURLtable, puedo abrir exitosamente mysql.exe o phpMyAdmin y use urls;. Incluso puedo show tables;ver la tabla esperada, pero luego, cuando intento describe urls;o select * from urls;, se queja de que la tabla no existe (aunquejustolo enumera). (El Administrador de MySQL enumera las bases de datos, pero ni siquiera enumera las tablas, indica que las bases de datos están completamente vacías).

El problema ahora es que ya eliminé el archivo SQL (y no puedo recuperarlo incluso después de limpiar mi disco duro). Así que estoy tratando de encontrar una manera de reparar estas bases de datos/tablas. No puedo usar la función de reparación de tablas porque se queja de que la tabla no existe y no puedo deshacerme de ellas porque nuevamente se queja de que las tablas no existen.

Como dije, los datos en sí todavía están presentes en los archivos .ibd y los nombres de las tablas están presentes. Sólo necesito una manera de hacer que MySQL reconozca que las tablas existen en las bases de datos (puedo encontrar los nombres de las columnas de las tablas en cuestión en el archivo ibdata1 usando un editor hexadecimal).

¿Alguna idea de cómo puedo reparar este tipo de corrupción? No me importa arremangarme, profundizar y tomar una serie de medidas para solucionarlo.

Muchas gracias.

Answer 1

Bueno, probé un montón de cosas e investigué un montón de comandos, conmutadores y estructuras (no es sorprendente que los documentos de MySQL fueran muy útiles, aunque extensos: aguja/pajar). Al final, algunos de mis trucos funcionaron (resulta que otros habían pensado en los mismos trucos, aunque no vi las dos partes principales (recuperar la estructura de la tabla y recuperar los datos) en un solo lugar, así que las publicaré juntas aquí).

Lo que tuve que hacer fue recrear el archivo IBDATA1. Desafortunadamente, mientras se ejecuta el demonio detecta las bases de datos (los directorios), no selecciona las tablas internas de Innodb (los archivos IBD/FRM). Entonces lo que hice fue:

1. Vacíe el directorio de datos (o mueva el original y cree uno vacío)
2. Ejecute el demonio y déjelo crear un archivo IBDATA1 nuevo y vacío.
3. Importe las tablas del sistema utilizando los scripts SQL en…\MySQL\share
4. Cree una base de datos ficticia y una tabla con el mismo nombre
5. Copie sobre el archivo FRM original
6. Utilice uno DESCRIBEo mejor SHOW TABLE CREATEpara extraer la estructura de la tabla
7. A continuación, usé DISCARD TABLESPACEen la mesa.
8. Copiado sobre el archivo IBD original.
9. Entonces uséIMPORT TABLESPACE
10. Finalmente, volví a ejecutar el demonio coninnodb-force-recovery=6
11. Y corrí mysqldumpa extraer las estructuras y los datos.

Por supuesto, no siempre fue fácil. Algunas tablas estaban bien, pero otras requirieron eliminar la tabla y la base de datos después de SHOW TABLE CREATEy usarlas para recrear la tabla antes de intentar importar los datos. Otros ni siquiera funcionaron tan lejos, y tuve que obtener manualmente los comentarios y nombres de las columnas del archivo FRM usando un editor hexadecimal (aunque descubrir cuáles eran los tipos de datos y atributos, claves, etc. era una mierda). disparar). Además, hubo muchos (demasiados) reinicios de demonios y clientes.

(Todavía estoy buscando una herramienta que analice directamente los archivos FRM/IBD (o al menos muestre la estructura de la tabla de un archivo FRM), pero parece que nadie se ha molestado en realizarles “ingeniería inversa” a pesar de que es de código abierto. y los formatos de archivo están disponibles públicamente. Parece que todo el mundo se muestra complaciente al utilizar las herramientas oficiales de MySQL, creando así una gran oportunidad para las empresas de recuperación de datos y las herramientas propietarias/comerciales).

La clave era trabajar siempre con el mínimo absoluto (por ejemplo, sólo el directorio MYSQL, es decir, las tablas del sistema). Desafortunadamente, si bien significaba que las cosas se simplificarían y sería más fácil trabajar con ellas, también significaba recuperar una tabla a la vez, lo cual no fue un gran problema para mí, pero para algunas personas podría serlo.

De todos modos, de las muchas páginas de recuperación de MySQL en Internet que vi durante los últimos días, unas pocas fueron bastante útiles y las agregaré una vez que revise mi historial para desenterrarlas.


Espero que esto pueda ayudar a otros en una situación similar.

Answer 2

Ser capaz de enumerar todas las tablas y bases de datos generalmente significa que los archivos *.frm están ahí. No significan que haya datos para ellos. ¿Has intentado iniciar tu proceso mysqld?forzando la recuperación de innodb? Si no, inténtalo, de si, ¿qué dice el log de mysql al iniciar?

Una vez hecho esto: nunca vuelvas a intentar utilizar copias de seguridad como esa.