Types de sauvegarde
Deux types de sauvegarde sont possibles comme sous Oracle :
Sauvegarde logique (ordre DDL et DML d’une ou plusieurs bases) aussi appelé DUMP :
#Création de l’export contenant toutes les bases de l’instance
mysqldump –user=mon_user –password=mon_password –all-databases > fichier_dump.sql
La sauvegarde logique peut être effectuée uniquement à chaud (instance démarrée) :
- A chaud, le dump va figer les données de la table qu’il va exporter en y apposant un verrou
Un dump va contenir les ordres de création d’une ou plusieurs bases, d’une ou plusieurs tables, de fonctions, de procédures et des autres objets contenus en base.
Par défaut, sans options spécifiques, l’export sera consistant quel que soit le moteur des tables (mélange de tables MyIsam et InnoDB par exemple).
L’option –single-transaction permettra de rendre consistant un export contenant uniquement des tables InnoDB :
#Création de l’export contenant toutes les bases de l’instance et ayant InnoDB comme moteur de tables
mysqldump –user=mon_user –password=mon_password –all-databases –single-transaction > fichier_dump.sql
Cette solution de sauvegarde logique permettra :
- Une sauvegarde et une restauration rapide lorsque la volumétrie de/des bases est faible
En cas de forte volumétrie, pour éviter un temps d’indisponibilité élevé, il sera préférable d’utiliser une sauvegarde physique.
Sauvegarde physique (copie physique des fichiers vitaux des bases de données) :
#Création d’une sauvegarde physique full avec l’outil Xtrabackup de Percona
xtrabackup –user=mon_user –password=mon_password –backup –target-dir=/backup/mon_backup_full
La sauvegarde physique peut être effectuée à froid comme à chaud :
- A froid, manuellement (sans outils de sauvegarde), cela ne pose aucun problème car il n’y a pas d’écriture dans les fichiers de données
- A froid et à chaud, avec un outil de sauvegarde, comme par exemple, Xtrabackup, de l’éditeur Percona (solution open source)
Il est préférable d’utiliser une solution de sauvegarde à chaud tel que Percona Xtrabackup. Cela permettra de garder l’intégrité, la cohérence des données et de minimiser l’impact sur les performances du serveur lors de la sauvegarde et de la restauration.
A noter, la possibilité d’effectuer un backup full et des backup incrémentaux.
Cette solution de sauvegarde physique (full ou incrémentale) permettra :
- Une sauvegarde et une restauration rapide quelle que soit la volumétrie
- Une sécurité plus importante car la sauvegarde contiendra une copie physique des fichiers de données des bases de données
- Une facilité d’administration quelle que soit la volumétrie
- Une consistance dans les données lorsque la sauvegarde contient à la fois des tables MyIsam et InnoDB
Restauration “Point In TIME”:
Les binary logs, appelés aussi : binlogs, sont essentiellement les journaux des événement transactionnel des bases. Ils ne contiennent pas seulement les ordres sql exécutés.
La mise en place de ce mécanisme de génération de binlog permettra une restauration des données “Point In Time”, mais aussi pour faire de la réplication de données sur un slave. Le mode archivelog d’une base Oracle est assez similaire.
La création de ces binlogs s’effectue via un paramétrage dans le fichier d’options my.cnf (nom des binlogs générés ainsi que leur dossier de destination, rétention des binlogs, taille maximale du binlog à atteindre avant de passer sur un nouveau fichier binlog) :
La restauration peut s’effectuer :
– Soit à partir du dump généré précédemment :
#Import du dump
mysql –user=mon_user –password=mon_password < fichier_dump.sql
– Soit à partir de la sauvegarde FULL (ou incrémentale) générée précédemment :
#Préparation du backup avant restauration(cette opération rend consistant les fichiers de données des tables InnoDB)
xtrabackup –prepare –target-dir=/backup/mon_backup_full
#Arret du service Mysql afin de stopper les écritures
service mysql.server stop
#Restauration du backup sans effacer le contenu du dossier source contenant la sauvegarde
xtrabackup –copy-back –datadir=/data/ –target-dir=/backup/mon_backup_full
#Démarrage du service Mysql
service mysql.server start
Grâce aux binlogs, une restauration “Point In Time” est possible (uniquement si nous avons en possession, les binlogs générés après l’exécution de l’export ou de la sauvegarde full ou incrémentale).
Pour restaurer l’ensemble des transactions exécutées après la génération du dump ou du backup physique, nous avons besoin de l’ensemble des binlogs contenant ces transactions à partir de la position visible soit dans l’entête du dump, soit dans le fichier xtrabackup_binlog_info d’une sauvegarde physique.
Exemple: #Restauration Point In Time des données à partir de la position 120 du binlog mysql-bin.000009
mysqlbinlog /binlog/mysql-bin.000009 /binlog/mysql-bin.000010 /binlog/mysql-bin.000011 /binlog/mysql-bin.000012 –start-position=120 | mysql -u root -p
Mise en garde : Dans le cas d’un ordre DDL DROP qui serait exécuté sur une table à 11h (position 2199 du fichier mysql-bin.000012) et qu’une restauration est effectuée Point In Time à 11h grâce aux binlogs, l’ordre de DROP serait bien entendu rejoué. Il faut donc restaurer les binlogs avant l’apparition de cet ordre DDL :
#Restauration Point In Time des données jusqu’à la position 2000 du binlog mysql-bin.000012
mysqlbinlog –stop-position=2000 /binlog/mysql-bin.000012 | mysql -u root -p
Article Applicable à partir de la version 5.5 de Mysql Server