J'ai accidentellement laissé tomber toutes les tables. Puis-je restaurer en arrière? Je n'ai pas la copie de sauvegarde.
J'ai accidentellement laissé tomber toutes les tables. Puis-je restaurer en arrière? Je n'ai pas la copie de sauvegarde.
Réponses:
Si vous n'avez littéralement aucune sauvegarde, je suis sûr à 99% que vous n'avez pas de chance.
Si vous avez une forme de sauvegarde, aussi ancienne soit-elle, la journalisation binaire est-elle activée via l'option log-bin dans le fichier de configuration MySQL (my.ini)? Si c'est le cas, vous pourrez peut-être les récupérer depuis la dernière sauvegarde.
Mauvaise façon de commencer un mec d'une semaine, désolé.
La question est assez ancienne, mais il n'y a pas de réponse positive unique, je vais donc en ajouter une.
Après que MySQL a déposé une table, les données sont toujours sur le support pendant un certain temps. Vous pouvez donc récupérer des enregistrements et reconstruire une table. Plus tard, je bloguerai à ce sujet, mais pour l'instant un croquis rapide.
Vous auriez besoin d'avoir la structure de votre table (instruction CREATE TABLE).
Si innodb_file_per_table est activé, la table supprimée se trouve sur la partition de disque. Arrêtez MySQL et remontez-le en lecture seule ASAP. Si MySQL était sur une partition racine (ce qui n'est pas une bonne idée entre autres), alors prenez une image ou retirez le disque et branchez-le sur un autre serveur. Arrêtez toutes les écritures en d'autres termes.
Si innodb_file_per_table est désactivé, arrêtez simplement MySQL.
Ensuite, téléchargez et compilez l'outil de suppression de InnoDB à partir de https://github.com/twindb/undrop-for-innodb/ . Consultez la publication « Compilation de la boîte à outils de récupération TwinDB » pour plus de détails.
Ensuite, analysez la partition de disque ou ibdata1 (selon le paramètre innodb_file_per_table) avec stream_parser:
./stream_parser -f /path/to/diskimage_or_ibdata1
Récupérez ensuite le dictionnaire InnoDB pour savoir dans quel index_id se trouvait la table supprimée.
Prenez ensuite la structure de la table et récupérez les enregistrements
./c_parser -f pages-diskimage_or_ibdata1/FIL_PAGE_INDEX/00000<index_id>.page
Il sortira les enregistrements vers stdout et la commande LOAD DATA vers stderr.
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. J'ai d'abord 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. Tue mysqld. ( ps auxpour trouver le PID, alors kill PID). MySQL redémarré, il a commencé en mode de récupération après incident. Ensuite, j'ai lancé mon client mysql local et généré un vidage complet des tables dont j'avais besoin.
Et, 15 000 lignes représentant des semaines de travail entrant dans les métadonnées que nous pensions avoir disparu pour toujours, sont enregistrées !!
J'espère que cela aide quelqu'un.
Malheureusement, vous ne pouvez pas faire grand-chose, à part tirer une leçon très précieuse sur la nécessité d'un bon plan de sauvegarde.
Selon le type de table, vous pourrez peut-être trouver un expert qui peut 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 très coûteuse (car elle nécessiterait des compétences relativement rares) et pas du tout garantie pour être vraiment utile.
S'il s'agissait d'une table MyISAM, il vous suffit de restaurer les fichiers de la table dans / var / log / mysql ou quel que soit votre répertoire de données. Vous pouvez utiliser l' utilitaire ext3grep pour cela par exemple.
Vous ne pouvez pas "défaire" a DROP TABLE.
Vous pouvez regarder et voir si MySQL a activé la journalisation binaire , vous pouvez peut-être en extraire certaines données.
En dehors de cela, vous pouvez oublier MySQL et vous êtes dans la même classe de problèmes "J'ai accidentellement supprimé certains fichiers de mon système de fichiers". Il existe des outils qui tentent de récupérer des fichiers, et il y a aussi des entreprises qui le font à titre professionnel.
Si la journalisation binaire est activée, vous pouvez simplement recréer une table en premier si vous avez un schéma. Assurez-vous que vous créez un schéma pendant que les journaux binaires sont désactivés. Ou vous pouvez simplement sauter pour la session. Ensuite, vous pouvez rejouer les binlogs jusqu'à la dernière instruction qui était la table de dépôt elle-même.
Sinon, vous pouvez restaurer à l'aide d'un vidage de sauvegarde si vous en avez. Si vous avez des fichiers csv, vous pouvez effectuer la méthode de chargement des fichiers pour récupérer les données. Si vous récupérez à partir de mysqldump, vous pouvez envisager de restaurer une seule table à partir du fichier de vidage plutôt que de restaurer la base de données complète. Si la taille des données est trop grande, vous pouvez envisager de désactiver les clés avant le chargement, ce qui augmentera considérablement le processus de restauration.
Pour l'avenir, vous aimerez peut-être avoir un esclave retardé quelque chose comme 10-24 heures de retard. Vous pouvez créer un esclave retardé à l'aide de la boîte à outils percona (pt-slave-delay)