Quelques méthodes avancées pour faire un backup MySQL/MariaDB

Cet article a été publié il y a 6 ans 6 mois 4 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Je suis récemment tombé sur cet article un peu provocateur indiquant que mysqldump n’était pas un outil de backup. Si l’on a un peu utilisé l’outil, et sur des bases conséquentes, ses arguments résonnent évidemment correctement, malgré tout pour certains sites, et notamment ce blog par exemple, il reste tout à fait pertinent. Le deuxième article est plus décevant en ça qu’il ne détaille pas réellement les techniques et contraintes de chaque solution proposée. J’ai donc décidé de reprendre un peu tout ça pour creuser un peu plus le sujet.

Pour rappel, mysqldump procède de manière séquentielle, il lit chaque table une par une pour en extraire le contenu et générer des requêtes SQL qui pourront rejouées pour injecter les données. Le souci, c’est que pour chaque table, il la verrouille pendant qu’il en parcourt le contenu, et donc, interrompt le travail du site concerné par la base jusqu’à ce qu’il ait fini. Dans le même esprit, entre le début et la fin, il peut y avoir eu des modifications et l’outil ne revient pas dessus, vos données peuvent donc être incohérentes.

MyISAM

Je ne vais pas m’attarder sur ce cas, il est déjà très détaillé et son utilisation est de plus en plus marginale et spécialisée. Ce sont sur les deux autres que je vais concentrer mes mots aujourd’hui.

Snapshot

Typiquement au travers d’LVM, le snapshot est une technique qui permet de prendre un instantané, de figer une version du système de fichiers. En montant cet instantané du système de fichiers dans un dossier particulier, cela permet de démarrer une deuxième instance Mysql à coté de celle qui bosse toujours pour en faire une vraie sauvegarde, qui sera assurément cohérente de bout en bout (puisqu’elle ne travaille pas), et qui ne bloque pas le travail en cours. La seule contrainte est de s’assurer que le snapshot a suffisamment de place dans son volume group, ce qui peut être un challenge sur des bases particulièrement sollicitées en écriture (et même en lecture parfois).

C’est une technique que l’on utilise souvent sur les instances MySQL que l’on installe chez LinkByNet, en plus d’utiliser des outils maisons pour sauvegarder chaque table de chaque base indépendamment afin de pouvoir faire une restauration extrêmement granulaire. Autant à titre personnel je ne m’en servirai probablement jamais, autant c’est une technique que je trouve élégante, bien qu’un peu touchy à mettre en place (on a des scripts déjà tout fait pour ça, mais dès qu’on sort de nos installations habituelles, c’est infernal).

On est même pas obligé de démarrer une instance et de lancer un dump, une simple copie du datadir peut suffire. Cependant, si lors de la restauration vous êtes contraints de changer de version de MySQL/MariaDB, le lancement risque d’être compliqué en raisons de différences mineures sur les formats de fichiers, et là un dump contenant des commandes SQL sera certes plus long à importer, mais autrement plus fiable.

XtraBackup

L’outil mis à disposition par la société Percona, qui distribue et commercialise des offres autour de leur variante de MySQL, qui est axée sur les performances, repose finalement sur une fonction avancée d’InnoDB : le « crash-recovery ». En clair, il procède classiquement à une synchronisation des fichiers (de la même façon que pour MyISAM comme le propose l’auteur), puis s’appuie sur la capacité de réparation d’InnoDB pour recaler les données de manière cohérente via le journal des transactions. Ce qui permet de faire une sauvegarde à chaud sans s’inquiéter de poser des verrous sur votre base. La documentation est évidemment en anglais et je vous laisse la lire si vous souhaitez vous faire mal au crâne (mais c’est super instructif).

C’est notamment la solution qu’on utilise sur un client dont la base de données fait 200Go et qui exploite une réplication master-slave. Quand l’interruption de réplication est trop longue pour relancer celle-ci à la main (avec un retard conséquent à rattraper), on procède via XtrBackup pour refaire l’instance slave de zéro, ce qui permet de limiter le temps de remise en service derrière.

Et vous, vous utilisez quoi ?

Perso, vu l’activité de mes bases mysqldump est largement suffisant et je n’ai pas besoin de mettre en place de procédures plus contraignantes. Mais on l’a vu, il n’est pas parfait non plus. LVM et XtraBackup sont des options qui ont l’avantage d’être gratuites, et je n’ai pas connaissance d’autres outils, mais vous peut-être ?