Une architecture basique de type Oracle-like
Une question est régulièrement posée au sujet de la possibilité de "multiplexer les redo" avec PostgreSQL. C'est du vocabulaire Oracle Database qui peut se traduire avec PostgreSQL par "Est-il possible d'écrire de manière synchrone les informations de journalisation WAL dans plusieurs emplacements différents ?"
L'idée derrière le fait de "multiplexer les redo" est de se prémunir des corruptions de filesystems et de diminuer le risque de perdre des transactions validées (assurer le D de ACID).
De manière plus générale, Oracle propose par défaut de créer une zone appelée FRA (Fast Recovery Area). Cette zone va contenir une copie des fichiers de journalisation courant (redo log online, WAL) mais aussi les fichiers de journalisation archivés (redo logs archivés, WAL archivés) et les sauvegardes des fichiers de données.
Le principe de sauvegarde est alors de faire "backup database to FRA" suivi de "backup FRA to tape". L'idée est de sauvegarder la base dans la FRA afin de disposer d'une zone disque immédiatement disponible pour faire des PITR (point in time recovery) rapides mais limités au niveau de la période couverte mais aussi de remonter la FRA sur bande pour constituer des sauvegardes de plus long terme. Les bandes sont souvent à présent des librairies virtuelles mais le principe demeure le même.
Nous allons constituer l'équivalent de la FRA pour PostgreSQL avec Barman, outil sous licence GPL édité par 2ndQuadrant. Cet outil est plutôt prévu pour faire des sauvegardes distantes mais qui peut le plus peut le moins et nous allons l'utiliser localement selon le schéma d'architecture suivant fourni dans leur documentation :
A présent, paramétrage du streaming et de l'archivage des WAL :
Nous constatons que le cluster est paramétré par défaut pour permettre le PITR (point in time recovery) et le streaming WAL. Le niveau de journalisation est en effet fixé à REPLICA. Cet aspect a été simplifié par rapport aux versions précédentes. Si vous ne voulez pas faire de PITR ou de réplication avec une standby alors le niveau à fixer est MINIMAL sinon il est à positionner à REPLICA. Un niveau supérieur à REPLICA existe, LOGICAL. Il permet de faire de la réplication logique, de décoder les WAL pour en extraire le SQL. Ce dernier niveau est équivalent à positionner le "supplemental logging" qui permet d'utiliser Streams ou Golden Gate avec Oracle Database.
Le nombre maximal de flux de streaming sortants est fixé à 10 via MAX_WAL_SENDERS tout comme le nombre de slots permettant d'éviter que les informations de journalisation soient supprimées avant d'avoir été transmises. Bref, rien à faire côté paramétrage pour le streaming WAL.
Au sujet de l'archivage des WAL, nous avons positionné archive_mode à ON et nous avons utilisé rsync pour archive_command. Les WAL archivés arriveront dans /var/lib/barman lorsque barman sera configuré. A noter que var/lib/barman doit bien sûr être un filesystem distinct de /var/lib/postgresql et pas seulement un dossier distinct.
Il faut aussi disposer d'un superutilisateur autorisé notamment à transmettre les informations WAL. Nous pourrions utiliser postgres mais nous allons créer un utilisateur dédié appelé localsuper en musclant sa méthode d'authentification au passage :
La méthode md5 étant toujours activée par défaut dans pg_hba.conf, nous allons remplacer md5 par scram-sha256 pour les connexions locales dans /etc/postgresql/10/apptra001/pg_hba.conf (en fait cela fonctionnerait en laissant md5 puisque md5 permet ici d'utiliser md5 et scram-sha256 mais nous allons ainsi interdire explicitement md5) :
Place à présent à la configuration de barman. Le fichier de configuraiton va être renseigné de manière à garantir une fenêtre de recover de 5 jours, c'est à dire qu'il sera toujours possible de faire revenir les bases du cluster en arrière de 5 jours avec ce que contient lespace Barman. Avec une sauvegarde planifiée de manière hebdomadaire, le nombre de sauvegardes présentes en ligne sera au maximum de 2 :
C'est fini pour la partie "postgres". À présent la partie "barman" en commançant par le stockage du mot de passe de localsuper dans un fichier dédié à l'accès restreint :
Tout est OK.
Dernier point. Pour avoir réellement une copie conforme du WAL courant dans cet espace Barman, il faut imposer la synchronisation au niveau du streaming WAL :
Attention à ce dernier point, il faut à présent absolument que le streaming WAL synchrone fonctionne pour pouvoir valider une transaction. Dans le cas contraire, c'est le blocage. Le fait de passer d'un RPO (recovery point objective, perte de données maximale admissible) proche de 0 à un RPO de 0 peut ainsi se payer par un risque accru sur la disponibilité ET la performance. Ce RPO de 0 s'entend de toute façon sous réserve de ne pas perdre simultanément /var/lib/barman ET /var/lib/postgresql. Il est recommandé d'avoir plusieurs destinations si vous mettez en place du streaming WAL synchrone (raisonnement proche de celui à avoir avec les Dataguard en "max protection" pour les DBA Oracle)
Comme d'habitude, il est possible d'automatiser tout cela via Ansible, de superviser le bon fonctionnement de l'ensemble via Nagios etc.
Mise à jour : 20/08/2018