¿Cómo deshacer DROP Table?

Accidentalmente se me cayeron todas las mesas. ¿Puedo restaurar de nuevo? No tengo la copia de respaldo.

Si literalmente no tiene respaldo, estoy 99% seguro de que no tiene suerte.

Si tiene alguna forma de copia de seguridad, por antigua que sea, ¿tiene activado el registro binario a través de la opción log-bin en el archivo de configuración de MySQL (my.ini)? Si es así, es posible que pueda recuperarse desde la última copia de seguridad.

Mala manera de comenzar una semana, amigo, lo siento.

La pregunta es bastante antigua, pero no hay una respuesta positiva única, por lo que agregaré una.

Después de que MySQL suelta una tabla, los datos permanecen en los medios por un tiempo. Entonces puede buscar registros y reconstruir una tabla. Más adelante escribiré un blog al respecto, pero por ahora esbozo rápido.

Necesitaría tener la estructura de su tabla (sentencia CREATE TABLE).

Si innodb_file_per_table está ENCENDIDO, la tabla descartada está en la partición del disco. Detenga MySQL y vuelva a montarlo como de solo lectura lo antes posible. Si MySQL estaba en una partición raíz (lo cual no es una buena idea, por cierto), tome una imagen o saque el disco y conéctelo a otro servidor. Detener todas las escrituras en otras palabras.

Si innodb_file_per_table está desactivado, simplemente detenga MySQL.

Luego descargue y compile la herramienta para soltar para InnoDB desde https://github.com/twindb/undrop-for-innodb/ . Consulte la publicación " Compilación del kit de herramientas de recuperación TwinDB " para obtener más información.

Luego, analice la partición de disco o ibdata1 (según la configuración de innodb_file_per_table) con stream_parser:

./stream_parser -f /path/to/diskimage_or_ibdata1

Luego recupere el diccionario InnoDB para saber en qué index_id estaba la tabla descartada.

Luego toma la estructura de la tabla y busca los registros

./c_parser -f pages-diskimage_or_ibdata1/FIL_PAGE_INDEX/00000<index_id>.page

Producirá registros a stdout y el comando LOAD DATA a stderr.

Esto es lo que hice. En el directorio mysql (para Ubuntu esto es / var / lib / mysql, para Mac usando Homebrew esto es / usr / local / var / mysql), encontré algunos archivos. Primero copié el directorio myapp_development / que contiene el esquema particular en mi directorio mysql local. Luego hice una copia de seguridad de mi ibdata1 local y copié la ibdata1 del servidor en el directorio mysql. Mató a mysqld. ( ps auxpara encontrar el PID, entonces kill PID). Reinicé mysql, comenzó en modo de recuperación de fallos. Luego encendí mi cliente mysql local y generé un volcado completo de las tablas que necesitaba.

¡Y se guardan 15,000 filas que representan semanas de trabajo ingresando metadatos que pensamos que se habían ido para siempre!

Espero que esto ayude a alguien.

Desafortunadamente, es muy poco lo que puede hacer, aparte de extraer una lección muy valiosa sobre la necesidad de un buen plan de respaldo.

Dependiendo del tipo de tabla, puede encontrar un experto que pueda reconstruir los datos de lo que dejó en el disco, pero dicho análisis forense sería muy, muy costoso (ya que requeriría habilidades relativamente poco comunes) y no está garantizado en absoluto para ser realmente útil

Si esta fue la tabla MyISAM, solo necesita recuperar los archivos de la tabla en / var / log / mysql o lo que sea su directorio de datos. Puede usar la utilidad ext3grep para eso, por ejemplo.

No se puede "deshacer" a DROP TABLE.

Puede ver si MySQL tenía habilitado el registro binario , tal vez pueda extraer algunos datos de allí.

Aparte de eso, puedes olvidarte de MySQL y estar en la misma clase de problemas de "Eliminé accidentalmente algunos archivos de mi sistema de archivos". Existen algunas herramientas que intentan recuperar archivos, y también hay empresas que lo hacen de manera profesional.

Si tiene activado el registro binario, puede volver a crear una tabla primero si tiene un esquema. Asegúrese de crear un esquema mientras tenga binlogs desactivados. O simplemente puede saltear la sesión. Luego, puede reproducir los binlogs hasta la última instrucción, que fue soltar la tabla.

Si no es así, puede restaurar utilizando un volcado de respaldo si tiene alguno. Si tiene archivos csv, puede cargar el método de archivo de datos para recuperar datos. Si se está recuperando de mysqldump, entonces puede considerar restaurar una sola tabla del archivo de volcado en lugar de restaurar la base de datos completa. Si el tamaño de los datos es demasiado grande, entonces puede considerar deshabilitar las claves antes de cargar esto, esto aumentará significativamente el proceso de restauración.

Para el futuro, es posible que desee tener un esclavo retrasado algo así como 10-24 horas atrás. Puede crear esclavos diferidos utilizando el kit de herramientas de percona (pt-slave-delay)