Comment annuler le DROP Table ?

Si vous n'avez littéralement aucune sauvegarde, je suis sûr à 99 % que vous n'avez pas de chance.

Si vous disposez d'une sauvegarde, aussi ancienne soit-elle, la journalisation binaire est-elle activée via l'option log-bin dans le fichier de configuration de MySQL (my.ini) ? Si c'est le cas, vous pourriez être en mesure de récupérer les données depuis la dernière sauvegarde.

Mauvaise façon de commencer la semaine, désolé.

La question est assez ancienne, mais il n'y a pas de réponse positive unique, alors j'en ajouterai une.

Lorsque MySQL supprime une table, les données restent sur le support pendant un certain temps. Vous pouvez donc récupérer des enregistrements et reconstruire une table. Je reviendrai plus tard sur ce sujet dans mon blog, mais pour l'instant, je vous propose une brève esquisse.

Vous devez disposer de la structure de votre table (instruction CREATE TABLE).

Si innodb_file_per_table est ON, les tables supprimées se trouvent sur la partition du disque. Arrêtez MySQL et remontez-la en lecture seule dès que possible. Si MySQL était sur une partition racine (ce qui n'est pas une bonne idée), prenez une image ou retirez le disque et branchez-le sur un autre serveur. En d'autres termes, arrêtez toutes les écritures.

Si innodb_file_per_table OFF, il suffit d'arrêter MySQL.

Ensuite, téléchargez et compilez l'outil un-drop pour InnoDB à partir de https://github.com/twindb/undrop-for-innodb/ . Consultez l'article "[Compilation du kit de récupération TwinDB][1]" pour plus de détails.

Puis analyser soit la partition du disque, soit ibdata1 (en fonction du paramètre innodb_file_per_table) avec stream_parser :

./stream_parser -f /path/to/diskimage_or_ibdata1

Ensuite, récupérez le dictionnaire InnoDB pour savoir dans quel index_id se trouvait la table supprimée.

Prenez ensuite la structure du tableau et récupérez les enregistrements.

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

Il enverra les enregistrements à stdout et la commande LOAD DATA à stderr. [1] : https://twindb.com/how-to-recover-innodb-dictionary/

P.S. tutoriel vidéo sur Undrop For InnoDB - Undrop for InnoDB overview https://youtu.be/-1LeLhGjAWM

Il n'y a malheureusement pas grand-chose à faire, si ce n'est retenir une leçon très précieuse sur la nécessité d'un bon plan de secours.

En fonction du type de table, vous pourrez peut-être trouver un expert capable de reconstituer les données à partir de ce qu'il a laissé sur le disque, mais une telle analyse médico-légale serait très très coûteuse (car elle nécessiterait des compétences relativement peu courantes) et son utilité ne serait pas du tout garantie.

Voici ce que j'ai fait. Dans le répertoire mysql (pour Ubuntu c'est /var/lib/mysql, pour Mac utilisant Homebrew c'est /usr/local/var/mysql), j'ai trouvé quelques fichiers. Tout d'abord, j'ai copié le répertoire myapp_development/ contenant le schéma particulier dans mon répertoire mysql local. Ensuite, j'ai sauvegardé mon ibdata1 local et copié l'ibdata1 du serveur dans le répertoire mysql. J'ai tué mysqld ( ps aux pour trouver le PID, puis kill PID ). Redémarrage de mysql, il a démarré en mode de récupération en cas de crash. J'ai ensuite lancé mon client mysql local et généré un dump complet des tables dont j'avais besoin.

Et 15 000 lignes représentant des semaines de travail à saisir des métadonnées que nous pensions disparues à jamais sont sauvées !

J'espère que cela aidera quelqu'un.

Il n'est pas possible d'annuler une DROP TABLE .

Vous pouvez vérifier si ce MySQL avait journalisation binaire a permis, peut-être, d'extraire quelques données.

À part cela, vous pouvez oublier MySQL et vous vous retrouvez dans la même catégorie de problèmes que "j'ai accidentellement supprimé des fichiers de mon système de fichiers". Il existe des outils qui tentent de récupérer les fichiers, ainsi que des entreprises qui s'en chargent de manière professionnelle.