16.9 Sauver et restaurer une base InnoDB
16 Tables InnoDB
Manuel de Référence MySQL 4.1 : Version Française
->Forcer la restauration
. Points de contrôle
|
16.9.1 Forcer la restauration
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.
|