Si actúa rápido, hay muchas posibilidades de recuperar su base de datos. La posibilidad es mayor para InnoDB, para MyISAM no es cero, pero está cerca.
El problema es cuando MySQL ejecuta DROP TABLE o DROP DATABASE (que es esencialmente lo mismo) InnoDB no borra los datos. Las páginas con los datos todavía están en el disco.
Dependiendo de la configuración de innodb_file_per_table, el proceso de recuperación varía. Si innodb_file_per_table está desactivado (predeterminado hasta 5.5), la tabla descartada permanece en ibdata1. Si innodb_file_per_table está activado (predeterminado a partir de 5.5), la tabla descartada estaba en el archivo .ibd respectivo. MySQL elimina este archivo cuando suelta la tabla.
Lo primero que debe hacer es detener cualquier posible escritura para que su tabla no se sobrescriba. Si innodb_file_per_table está desactivado, es suficiente para detener MySQL (kill -9 es incluso mejor, pero asegúrese de matar safe_mysqld primero). Si innodb_file_per_table está activado, desmonte la partición donde MySQL almacena sus datos. Si el datadir está en la partición raíz, recomiendo cerrar el servidor o al menos tomar una imagen del disco. Permítanme repetir, el objetivo es evitar sobrescribir la tabla caída por MySQL o el sistema operativo.
Existe una herramienta que permite trabajar con páginas InnoDB a bajo nivel, el
kit de herramientas de recuperación de datos TwinDB . Lo usaré para ilustrar la recuperación de la caída.
Debe tomar los medios con la tabla caída (ya sea ibdata1 o imagen de disco) y buscar páginas de InnoDB en él. La herramienta stream_parser del kit de herramientas lo hace.
./stream_parser -f /path/to/disk/image
Escaneará el archivo, buscará las páginas de InnoDB y las ordenará por tipo e index_id. index_id es un identificador que InnoDB usa para referirse a un índice. Una tabla se almacena en el índice PRIMARIO. Para encontrar qué index_id es su tabla descartada, necesita recuperar el diccionario InnoDB .
El diccionario InnoDB se almacena en el archivo ibdat1. Necesita escanear el archivo ibdata1 de la misma manera que arriba:
./stream_parser -f /var/lib/mysql/ibdata1
Ahora necesita obtener registros de las tablas del diccionario InnoDB SYS_TABLES y SYS_INDEXES (supongamos que su tabla es sakila.actor):
./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql | grep sakila/actor
000000000B28 2A000001430D4D SYS_TABLES "sakila/actor" 158 4 1 0 0 "" 0
158 es table_id, recuérdalo.
./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000003.page -t dictionary/SYS_INDEXES.sql | grep 158
000000000B28 2A000001430BCA SYS_INDEXES 158 376 "PRIMARY" 1 3 0 4294967295
000000000B28 2A000001430C3C SYS_INDEXES 158 377 "idx\_actor\_last\_name" 1 0 0 4294967295
Entonces, index_id de su tabla descartada (sakila.actor) es 376.
Ahora puede obtener registros de la tabla eliminada de InnoDB index_id 376. Debe tener la estructura de la tabla eliminada, exactamente la instrucción CREATE TABLE con la que se creó la tabla. ¿Dónde puedes conseguirlo? Ya sea de una copia de seguridad anterior o de otra parte. También es posible recuperar la estructura del diccionario InnoDB, pero no lo cubriré en esta respuesta. Asumamos que lo tienes.
./c_parser -6f pages-ibdata1/FIL_PAGE_INDEX/0000000000000376.page -t actor.sql > dump.tsv 2> load_cmd.sql
c_parser genera registros como volcado separado por tabulaciones en stdout. El volcado se puede cargar con el comando LOAD DATA. c_parser lo imprime en stderr.
Ver más detalles en publicaciones: