La sauvegarde de MySQL Server avec Percona Xtrabackup
27 décembre 2018
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
Au 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
- 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.
- 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.