J'ai accidentellement supprimé un grand nombre de lignes d'une table...
Comment puis-je faire marche arrière ?
J'ai exécuté la requête en utilisant PuTTY .
Je serai reconnaissant si l'un d'entre vous peut me guider en toute sécurité hors de cette...
Donc il n'y a aucun moyen d'annuler cela .... Oups, je l'ai mal fait... Je devrais utiliser la requête select pour lister ce que je dois supprimer avant d'exécuter la requête... Une bonne leçon pour être plus prudent.
Malheureusement, c'est le cas. et oui, c'est toujours une bonne idée de vérifier avec select avant d'utiliser delete ou update.
C'est l'un des défauts des bases de données standard : Elles n'ont pas d'histoire, juste une énorme mémoire du "maintenant".
Si vous n'avez pas encore validé la transaction, essayez rollback . Si vous avez déjà validé la transaction (en exécutant manuellement la commande commit ou en quittant le client de la ligne de commande ou lorsque l'option autocommit es 1 qui est la valeur par défaut), vous devez restaurer les données de votre dernière sauvegarde.
Pour éviter ce genre de choses à l'avenir, utilisez la méthode suivante SET autocommit=0 avant tout travail dangereux. Tous les changements seront conservés à l'intérieur de votre transaction actuelle jusqu'à ce que vous les livriez. Voir https://dev.mysql.com/doc/refman/8.0/en/innodb-autocommit-commit-rollback.html pour plus de détails
Par défaut, le client en ligne de commande utilise la validation automatique après chaque commande.
Cela fonctionnerait en effet mais si et seulement si il utilise explicitement des transactions lors de l'exécution de sa requête de suppression, sinon il ne peut pas faire de "rollback".
Un "rollback" ne fonctionne que si vous avez utilisé transactions . De cette façon, vous pouvez regrouper des requêtes et annuler toutes les requêtes si une seule d'entre elles échoue.
Mais si vous avez déjà validé la transaction (ou utilisé une requête DELETE normale), le seul moyen de récupérer vos données est de les récupérer à partir d'une sauvegarde effectuée précédemment.
La réponse acceptée n'est pas toujours correcte. Si vous configurez la journalisation binaire sur MySQL, vous pouvez revenir à n'importe quel point antérieur de la base de données pour lequel vous disposez encore d'un instantané et d'un journal binaire.
7.5 Récupération ponctuelle (incrémentielle) à l'aide du journal binaire est un bon point de départ pour apprendre à connaître cette installation.
J'ai un doute. Si la journalisation binaire est activée, je pense qu'il y aura des bases de données de couverture sous un serveur mysql. Donc les choses que nous devons considérer, 1. si nous utilisons cette option pour récupérer pour un db, nous finissons par récupérer pour tous les 2. Et j'ai raison, même si nous utilisons le journal binaire pour la récupération ponctuelle, cela aide lorsque nous avons une sauvegarde du serveur/db pour commencer le processus de restauration
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Il est peut-être déjà tard, mais consultez également la réponse de Phil concernant l'enregistrement binaire.