Réflexions sur l'archivage des fichiers WAL

30/12/2015, 22:01:20

PostgreSQL faisant son bonhomme de chemin, on se retrouve désormais avec des configurations où il faut archiver plusieurs fois les WAL parce qu'on a de la sauvegarde PITR et de la réplication.

Le plus gros piège lorsqu'on a du PITR et de la réplication, ou plusieurs serveurs standby, c'est d'oublier que chaque élément de l'architecture qui consomme du WAL doit avoir son propre répertoire de WAL archivés, car chacun purge les fichiers différemment.

On tombe dans le piège facilement, en se disant, "pas de problème pour la purge des vieux fichiers, c'est le PITR ou le slave le plus éloigné qui purgera". Si la purge du PITR passe alors que le standby était déconnecté du maitre, cette purge peut casser la réplication.

La solution est d'archiver plusieurs fois le même fichier WAL. Pour optimiser, le plus efficace à l'usage est d'utiliser des hardlinks. En gros, on archive une fois le fichier WAL et on crée autant de lien hard qu'il faut pour les autres consommateurs de WAL archivés. Rappelons, que la donnée n'est supprimée que lorsqu'il n'existe plus aucun lien et que plus aucun processus n'a le fichier ouvert, à ne pas confondre avec un lien symbolique.

Pour archiver vite, il vaut mieux éviter de compresser et stocker les archives soit en local, soit sur un partage NFS, l'archivage par SSH restant le plus lent. Tout est compromis entre chiffrage des communications sur le réseau et espace disque disponible, les liens hard restant rapides à créer et avec une consommation d'espace disque supplémentaire négligeable.

Enfin, PostgreSQL exécute la commande d'archivage avec l'appel system() qui fork un shell : toutes les possibilités du shell sont alors disponibles, par exemple :

archive_command = 'rsync -a %p slave1:/archived_xlog/slave1/%f && ssh slave1 "for h in slave2 pitr; do ln /archived_xlog/slave1/%f /archived_xlog/$h/%f; done"'

Oui, une boucle et une seule copie avec rsync par SSH pour 3 utilisations. On préfèrera surement faire un script pour rendre les choses plus lisibles. Ça marche aussi pour restore_command et archive_cleanup_command dans recovery.conf :

restore_command = 'cp /archived_xlog/$(hostname)/%f %p'
archive_cleanup_command = 'pg_archivecleanup /archived_xlog/$(hostname) %r'

pitrery 1.10

21/10/2015, 18:42:20

Un semaine après la sortie de la version 1.9, un collègue découvre un bug dans le strict de restore des fichiers WAL, restore_xlog. Lorsqu'on utilise SSH pour stocker les archives des fichiers WAL, le script ne tient pas compte des paramètres spécifiant l'utilisateur et la machine distante en provenance du fichier de configuration.

Ce qui fait que la restore ne fonctionne pas lorsqu'on démarre PostgreSQL à moins de modifier l'appel à restore_xlog dans le paramètre restore_command du fichier recovery.conf pour y indiquer ces deux informations, car en ligne de commande ils sont bien pris en compte.

On peut aussi ajouter dans le fichier de configuration :

RESTORE_COMMAND="/path/to/restore_xlog -C <config_file> -h <archive_host> -u <archive_user> %f %p"

La version 1.10 corrige ce problème, voir le site de pitrery.

pitrery 1.9

13/10/2015, 11:33:28

La version 1.9 de pitrery vient de sortir. pitrery est un outil de sauvegarde PITR pour PostgreSQL, qui se focalise sur la sauvegarde d'une instance et la préparation de la restauration. Il est sous la même license que PostgreSQL.

Volontairement simple en terme de fonctionnalités (backup, restore, list et purge), il fournit également des scripts pour gérer l'archivage des journaux de transaction, sans imposer leur utilisation. L'objectif est de sauvegarder et restaurer en ligne de commande avec un outil facile d'utilisation. On peut d'ailleurs surcharger les paramètres trouvés dans le fichier de configuration pour adapter le comportement de l'outil à l'exécution.

Cette dernière version, apporte :

Le site de pitrery, contient le code source, les packages et la documentation.

pg_back 1.2

06/10/2015, 12:47:22

pg_back est sorti en version 1.2 depuis quelques semaines et je n'avais pas encore eu le temps de présenter les nouvelles fonctionnalités ajoutées dans cette version.

L'objectif de pg_back reste toujours d'être un script assez simple pour être modifié, adapté. Il ne faut donc pas hésiter à le modifier pour son propre usage. Je me concentre donc sur des fonctionnalités absolument indispensables.

La version apporte ainsi deux nouvelles fonctionnalités indispensables. En premier, des messages horodatés un peu partout pour avoir des logs d'exécution facilement exploitables, avec un "quiet mode" pour les désactiver. La seconde fonctionnalité permet de lancer pg_back directement sur un serveur hot-standby, celui-ci se charge alors de mettre en pause le rejeu des transactions durant le dump, cela permet d'éviter l'annulation des dumps à cuase de la réplication.

pg_back est disponible sur github, https://github.com/orgrim/pg_back.

pg_back le script de base pour sauvegarder PostgreSQL

12/03/2015, 16:24:50

Il y a fort longtemps, et c'est ma première contribution relative à PostgreSQL, j'ai écrit un script de backup qui dump tout un serveur PostgreSQL avec pg_dump et pg_dumpall. Il s'agit de pg_back.

Cela peut paraître curieux de publier un simple script de sauvegarde que tout DBA PostgreSQL a écrit dans sa vie et sait écrire par cœur. Surtout qu'on le réécrit en permanence ce script, pour ajuster des chemins, des cas particuliers du serveur à sauvegarder et de l'environnement où l'on sauvegarde...

En bien justement, c'est parce qu'on le réécrit tout le temps que pg_back fait gagner du temps. Il est simple et court, facilement lisible, c'est du shell : tout ce qu'il faut pour en faire une bonne base pour créer un script de sauvegarde adapté. Quand on l'utilise comme patron pour en faire un outil plus évolué, on gagne du temps.

Justement rajouter du code pour l'adapter peut se faire au début. Si on n'a pas envie d'utiliser le fichier de configuration, on adapte la liste de variables au début du script, quitte à en rajouter.

L'autre endroit intéressant c'est tout à la fin, avant le exit, on peut rajouter tout ce qu'il faut pour externaliser ses sauvegardes.

C'est par ici.