La sauvegarde de MySQL Server avec Percona Xtrabackup

La version communautaire de MySQL Server ne possède pas d’outils capables de faire de hot backup. Seule la version commerciale dispose de cette fonctionnalité ! Le logiciel Open Source Percona Xtrabackup permet de réaliser ce type de sauvegarde indispensable à l’exploitation d’une base de données transactionnelle et relationnelle.

Pré-requis

La sauvegarde de MySQL Server avec Percona XtrabackupAu cas où vous feriez le choix de compresser vos sauvegardes, vous devrez installer qpress sur votre distribution Linux. J’ai même fait le choix de compiler qzip, qunzip et qcat. C’est, au passage, parfaitement inutile.

wget -U firefox http://www.quicklz.com/qpress-11-linux-x64.tar
tar xvf qpress-11-linux-x64.tar
mv qpress /usr/bin
aptitude install make gcc python-dev
wget -U firefox http://www.quicklz.com/qzip.tar
tar xvf qzip.tar
make
mv qzip /usr/bin
mv qunzip /usr/bin
mv qcat /usr/bin

Installer Percona Xtrabackup sur Ubuntu 18.04

L’installation sur Ubuntu Bionic se fait en deux commandes, à l’aide de gdebi :

wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-8.0.4/binary/debian/bionic/x86_64/percona-xtrabackup-80_8.0.4-1.bionic_amd64.deb
gdebi percona-xtrabackup-80_8.0.4-1.bionic_amd64.deb

La sauvegarde complète

Que ce soit avec RMAN et les ARCHIVE LOG dans Oracle Database, le archive mode de PostgreSQL  ou dans SQL Server, la récupération d’une base à un instant donné de son activité suppose au préalable de disposer d’une sauvegarde complète incluant les données de l’ordonnanceur interne et les transactions validées et en cours de validation. Le répertoire de sauvegarde /backups/complete/ utilisé dans l’exemple doit être vide. S’il n’existe pas, la commande le crée !

xtrabackup --backup --target-dir=/backups/complete/ -u root --compress --compress-threads=4 --parallel=4 -p

Les 196 Mo de l’instance pèsent 7 Mo à l’arrivée. La sauvegarde aura pris moins de 5 secondes, du fait de l’utilisation de 4 threads calés sur les 4 cœurs de la machine.

La sauvegarde incrémentale

Au cours de la journée, à espace régulier, vous devrez planifier une sauvegarde incrémentale afin de disposer de l’historique des transactions et des modifications apportées à l’instance MySQL. Remarquez que la 1ère sauvegarde incrémentale a comme point de référence la sauvegarde complète.

xtrabackup --backup --target-dir=/backups/incremental/1 --incremental-basedir=/backups/complete -u root -p --compress --compress-threads=4 --parallel=4

La 2e sauvegarde incrémentale va avoir la 1ère incrémentale comme nouveau point de référence. Et ainsi de suite.

xtrabackup --backup --target-dir=/backups/incremental/2/ --incremental-basedir=/backups/incremental/1/ -u root -p --compress --compress-threads=4 --parallel=4

Restauration de la sauvegarde complète

Au travers des commandes qui suivent, je décompresse, puis je « prépare » le backup en vue de la restauration. Après l’arrêt du service, le répertoire /var/lib/mysql/ doit être vidé de ses données. Une fois la restauration effectuée, vous devez ensuite remettre les droits à l’utilisateur mysql. Enfin, relancez le service.

xtrabackup --decompress --parallel=4 --target-dir=/backups/complete/
xtrabackup --prepare --parallel=4 --target-dir=/backups/complete/
systemctl stop mysql
rm -fr /var/lib/mysql/*
xtrabackup --copy-back --parallel=4 --target-dir=/backups/complete/
chown mysql:mysql /var/lib/mysql -R
systemctl start mysql

Restauration de la sauvegarde incrémentale

La restauration d’une sauvegarde incrémentale suppose de connaître le point précis de l’incident qui a entraîné la perte de données. Le seul élément à notre disposition est en général l’heure  à laquelle la sauvegarde incrémentale a été effectuée. Il faut donc rejouer les sauvegardes incrémentales réalisées au plus près de l’incident, un peu avant. Le risque de pertes de données n’est donc pas complètement négligeable. Xtrabackup, comme la version communautaire de MySQL Server, reste extrêmement perfectible !

Après la décompression des sauvegardes incrémentales, préparez votre restauration. Arrêtez le service. videz le répertoire des données. Restaurez. Remettez les droits aux fichiers du répertoire /var/lib/mysql/ à l’utilisateur mysql, avant de relancer le service.

xtrabackup --decompress --parallel=4 --target-dir=/backups/incremental/1/
xtrabackup --decompress --parallel=4 --target-dir=/backups/incremental/2/
xtrabackup --prepare --parallel=4 --apply-log-only --target-dir=/backups/complete/
xtrabackup --prepare --parallel=4 --apply-log-only --target-dir=/backups/complete/ --incremental-dir=/backups/incremental/1/
xtrabackup --prepare --parallel=4 --apply-log-only --target-dir=/backups/complete/ --incremental-dir=/backups/incremental/2/
systemctl stop mysql
rm -fr /var/lib/mysql/*
xtrabackup --copy-back --parallel=4 --target-dir=/backups/complete/
chown mysql:mysql /var/lib/mysql -R
systemctl start mysql

Remarques

  1. J’avais eu cette très mauvaise idée de stocker mes fichiers pem liés à la prise en charge du SSL dans le dossier /var/lib/mysql. Ils n’ont pas survécu à l’exécution de la commande rm. Idem pour mon fichier mysql-auto.cnf. Curieusement, mon fichier auto.cnf a lui aussi disparu après la restauration et le redémarrage de l’instance ! La dernière version de Xtrabackup avec MySQL Server 8 pose encore de sérieux problèmes de compatibilité, qui m’amènent à douter de son utilisation en production.
  2. Prenez soin de conserver une copie de vos fichiers binlog, après un FLUSH LOGS si vous avez la main sur l’instance. Les fichiers binlog, s’ils ne sont pas sauvegardés, seront tout bonnement effacés. Avec un dump et les fichiers binlog, vous finirez toujours par retrouver vos petits !

Conclusion

Xtrabackup est une véritable usine à gaz très perfectible ! L’outil a toutefois le mérite d’exister.

 

MySQL / ,