- Documentation Library
- Table of Contents
- MySQL 5.0 Manual
- Table of Contents
- 5.7 Prévention des désastres et restauration
- 5.7.1 Sauvegardes de base de données
- 5.7.2 Exemples de stratégie de sauvegarde et restauration
- 5.7.3 Utilisation de myisamchk pour la maintenance des tables et leur recouvrement
- 5.7.4 Mettre en place un régime d'entretien de MySQL
- 5.7.5 Obtenir des informations sur une table
[+/-]
Cette section présente une procédure pour effectuer des sauvegardes qui vous permettent de retrouver vos données après différents types de problèmes :
Arrêt du système d'exploitation
Problème d'alimentation électrique
Problème du système de fichiers
Problème matériel : disque dur, carte mère, etc.
Les instructions suivantes requièrent l'utilisation de la version minimale de MySQL 4.1.8, car certaines options de mysqldump utilisées ici ne sont pas disponibles dans les précédentes versions.
Les commandes d'exemples n'inclut pas les options telles que
--user et --password avec les
utilitaires mysqldump et
mysql. Il vous faudra les ajouter en fonction
des besoins, pour que MySQL puisse se connecter au serveur.
Nous considèrerons les données stockées dans une table de
moteur InnoDB, qui supporte les transaction
et la restauration automatique. Nous supposerons que le serveur
MySQL est en charge au moment de la panne. Si ce n'est pas le
cas, aucune restauration ne sera nécessaire.
Dans les cas de panne du système d'exploitation ou de
l'alimentation électrique, on peut supposer que les disques de
données MySQL sont toujours disponibles après un redémarrage.
Les fichiers de données InnoDB sont
analysés, et à partir des logs, on peut retrouver la liste des
transactions archivées et non-archivées, qui n'ont pas encore
été écrites sur le disque. Le moteur de table va alors
annuler automatiquement les transactions qui n'ont pas été
terminées. Le détail des opérations du processus de
restauration est fourni à l'administrateur dans le fichier de
log d'erreur de MySQL. Voici un extrait :
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections
Dans le cas d'une panne du système de fichiers ou du matériel, nous pouvons supposer que les données MySQL ne sont plus disponibles après le redémarrage. Cela signifie que MySQL ne pourra pas démarrer corerctement, car certains blocs de données ne seront plus lisibles. Dans ce cas, il est nécessaire de formatter le disque, d'en installer un nouveau ou bien de corriger le problème sous-jacent. Puis, il faut restaurer les données à partir des sauvegardes : cela signifie que nous devons avoir déjà fait des sauvegardes. Pour s'assurer que c'est le cas, voyons comment se déroule un processus de sauvegarde.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.
