:: DEVELOPER ZONE
S'il survient une corruption de base de données, vous souhaiterez
exporter vos tables de la base avec SELECT INTO OUTFILE,
et généralement, la plupart des données seront intactes et correctes.
Mais la correction peut faire que SELECT * FROM table ou une
opération en tâche de fond d'InnoDB crashe, ou même,
que le processus de récupération de InnoDB crashe. Depuis InnoDB
version 3.23.44, il y a une option du fichier d'options qui vous
permet de forcer InnoDB a démarrer, et vous permet d'éviter le lancement
des opérations en tâche de fond, pour que vous puissiez exporter vos tables.
Par exemple, vous pouvez configurer :
[mysqld] innodb_force_recovery = 4
Avant MySQL 4.0, utilisez cette syntaxe :
[mysqld] set-variable = innodb_force_recovery=4
Les autres possibilités pour innodb_force_recovery sont listées ci-dessous.
La base ne doit pas être utilisée lorsque vous utilisez ces options.
Comme mesure de sécurité, InnoDB empêchera un utilisateur de faire des
commandes INSERT, UPDATE et DELETE lorsque cette
option est supérieure à 0.
Depuis la version 3.23.53 et 4.0.4, vous êtes autorisés à utiliser les commandes
DROP et CREATE sur une table, même si la restauration forcée est
active. Si vous savez qu'une table particulière vous pose des problèmes,
vous pouvez l'effacer. Vous pouvez aussi utiliser cette commande pour
stopper une annulation sauvage, qui seraient causée par des importations
de masse ou ALTER TABLE. Vous pouvez tuer le processu mysqld
et utiliser l'option innodb_force_recovery=3 pour
relancer votre base sans l'annulation. Alors, la suppression de la table
avec DROP vous aidera.
Un nombre plus grand signifie que toutes les précautions des nombres
inférieurs sont inclus. Si vous êtes capables d'exporter vos tables avec
une option au maximum de 4, alors vous êtes sûr que très peu de données
sont perdues. L'option 6 est plus dramatique, car les pages de la base de données
sont laissées dans un état obsolète, et cela va introduire encore plus de
corruption dans les arbres B-tree et les structures de la base.
1 (SRV_FORCE_IGNORE_CORRUPT) laisse le serveur fonctionner même s'il détecte une
page corrompue. Essaie d'éviter les index et pages avec SELECT * FROM table, ce qui
aide à l'export.
2 (SRV_FORCE_NO_BACKGROUND) empêche le thread principal de fonctionner. Si un crash survenait durant la purge, cela l'évitera.
3 (SRV_FORCE_NO_TRX_UNDO) ne lance pas les annulations de transactions après la restauration.
4 (SRV_FORCE_NO_IBUF_MERGE) empêche les opérations de vidange du buffer d'insertion. Si ce sont eux qui causent le crash, il vaut mieux les ignorer. Ne recalcule pas les statisttiques de tables.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN) ne regarde pas les logs d'annulations
lors du lancement de la base. InnoDB va traiter les transactions,
même incomplètes, comme validées.
6 (SRV_FORCE_NO_LOG_REDO) ne lance pas le rattrapage des opérations avec le log, après la restauration.
© 1995-2005 MySQL AB. All rights reserved.
