Présentation :
Ce message est une copie du merveilleux message suivant :
https://blackbird.si/mysql-corrupted-innodb-tables-recovery-step-by-step-guide/https://blackbird .si/mysql-corrupted-innodb-tables-recovery-step-by-step-guide/
Voici quelques exercices importants :
MySQL – Récupération de tables InnoDB corrompues – Guide étape par étape
Publié dans Bases de données Par Alen Krmelj Le 19 mars 2013, 5-6 minutes
Les tables InnoDB ne sont pas facilement corrompues, mais lorsqu'elles le sont, cela se produit généralement en raison de problèmes matériels, de pannes de courant ou d'un bogue MySQL. Cela vous laisse avec des pages corrompues dans l'espace de table InnoDB et la récupération à partir de cela pourrait être un problème. Lorsque votre MySQL se bloque correctement et ne veut pas revenir, vous pouvez voir une boucle d'erreur similaire :
InnoDB: Assertion failure in thread 1129654592 in file ibuf0ibuf.c line 4231 InnoDB: Failing assertion: page_get_n_recs(page) > 1 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. ... some backtrace ... The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. mysqld_safe Number of processes running now: 0 mysqld_safe mysqld restarted
Récupération à partir de tables InnoDB corrompues
Étape 1 – Mettez votre base de données en mode de récupération
Vous devriez supprimer votre base de données. Arrêtez-le au cas où il serait toujours en cours d'exécution et spammerait ces messages dans votre journal. En dernier recours, vous pouvez également tuer le processus. Afin de restaurer votre base de données, vous devrez la démarrer en mode de récupération, avec innodb_force_recovery . Vous devez savoir que ce mode de récupération rend vos bases de données en lecture seule. Les utilisateurs qui s'y connectent ne peuvent pas mettre à jour, insérer ou modifier de toute autre manière les données existantes. Pour éviter que votre MySQL ne soit martelé à la seconde où il revient, je vous suggère également de changer le port du serveur MySQL de 3306 à quelque chose d'aléatoire. Ajouter innodb_force_recovery=1 à votre my.cnf Si votre serveur ne veut pas revenir, vous pouvez encore augmenter ce nombre de 1 à 6, consultez le manuel de MySQL pour voir quelles sont les différences.
Assurez-vous de vérifier vos journaux MySQL, et s'il boucle avec quelque chose comme :
InnoDB: Waiting for the background threads to start
Vous devez également ajouter innodb_purge_threads=0 à votre my.cnf .
Donc tous ensemble pour ramener la base de données, j'ai dû ajouter ces 3 paramètres dans my.cnf :
port = 8881 innodb_force_recovery=3 innodb_purge_threads=0
Étape 2 - Vérifiez quelles tables sont corrompues et faites une liste
Maintenant, votre base de données est sauvegardée et en cours d'exécution, mais en mode de récupération. Vous ne pouvez pas modifier vos bases de données/tables. Si vous l'essayez, vous obtiendrez une erreur :
Got error -1 from storage engine
Nous devons découvrir quelles tables ont été corrompues. Pour ce faire, nous exécutons :mysqlcheck --all-databases
Vérifiez les lignes où il est indiqué que la table est corrompue. Notez toutes les tables / bases de données qui vous ont donné une erreur. Vous aurez besoin de mysqldump en mode de récupération et réimportez-les après avoir redémarré en mode MySQL normal. Permettez-moi également de vous rappeler que innochecksum La commande ne m'a pas aidé à découvrir quelles tables sont corrompues, alors ne vous en souciez pas.
Étape 3 - Sauvegardez et supprimez vos tables corrompues
Une fois que vous avez obtenu la liste des tables corrompues, vous devez mysqldump dans leurs propres fichiers .sql, de cette façon vous aurez une sauvegarde pour la réimportation. Au cas où vous vous demanderiez comment vider une seule table dans la base de données :
mysqldump my_database table> database.table.sql
Une fois que vous avez la sauvegarde, supprimez vos tables corrompues en exécutant :drop table database.table; depuis votre shell MySQL. Vous avez maintenant nettoyé votre base de données MySQL, il est donc temps de la redémarrer sans mode de récupération.
Étape 4 - Redémarrez MySQL en mode normal
Lorsque nous n'avons plus de tables corrompues dans notre base de données, nous devons supprimer les paramètres my.cnf que nous avons ajoutés à l'étape 1. Ne supprimez pas encore le paramètre de port, car il manque toujours à votre base de données les tables que vous avez sauvegardées et dont vous avez besoin. être réimporté. Redémarrez votre MySQL.
Étape 5 - Importer le fichier .sql de sauvegarde
Importez chaque table .sql vidée dans leur base de données respectée. Pour le faire depuis la CLI :
mysql database < database.table.sql
Étape 6 :Changez de porto et prenez une bière
Une fois que vous avez fini d'importer vos tables, vous êtes libre de modifier le paramètre de port dans votre my.cnf . Bien sûr, redémarrez MySQL après. Il devrait revenir et commencer à fonctionner comme avant le crash. Prenez une bière et cliquez en haut de cet article pour me faire savoir que cet article vous a aidé à résoudre votre problème.