Replication on Carnet de découvertes

Le jour où tout bascule

Florent Jardin — Thu, 19 Dec 2019 17:00:00 +0200

Lorsque l’on exploite une plateforme PostgreSQL avec de la réplication, il est exceptionnel de devoir déclencher le plan de bascule, rédigé par un ancien collègue ou un prestataire oublié. Ce genre de décision se prend lorsque l’ensemble des experts ont individuellement déterminé qu’aucune autre solution n’était envisageable.

Quels moyens a-t-on avec une architecture PostgreSQL dans son plus simple appareil pour réaliser une bascule des rôles et raccrocher les instances secondaires au nouveau primaire fraîchement élu ?

Mise en place

Partons du postulat que l’architecture la plus simple en terme de haute-disponibilité avec PostgreSQL est constituée de deux services avec une réplication physique d’une instance primaire vers une instance secondaire.

Pour des raisons de coûts, aucun serveur supplémentaire n’est alloué pour accueillir les archives de journaux de transactions, et ces derniers seront déplacés sur le serveur secondaire avec la commande rsync.

Et puisque la version 12 apporte des nouveautés notables sur la gestion d’une réplication, nous l’employerons dans cet article pour configurer nos instances sans le fichier recovery.conf. Pour la facilité de lecture, je baptiserai volontairement les deux serveurs : batman et robin.

L’instance batman dispose de la configuration suivante :

# postgresql.auto.conf
port = 5432
archive_mode = on
wal_log_hints = on
archive_command = 'rsync -a %p robin:/opt/batcave/%f'
restore_command = 'cp /opt/batcave/%f %p'
archive_cleanup_command = 'pg_archivecleanup /opt/batcave %r'
primary_conninfo = 'host=batman user=streamer'

Le fichier postgresql.auto.conf permet de surcharger les valeurs présentes dans le fichier standard postgresql.conf et, avantage certain sur une distribution Debian & co, il est accessible dans le répertoire de données PGDATA et pourra être copié en l’état vers toutes les instances secondaires au moment de leur création.

Cette étape par ailleurs repose sur un outil simple et fourni avec toutes les versions PostgreSQL : pg_basebackup. L’unique prérequis est de disposer d’un compte de réplication sur l’instance à répliquer et que le serveur distant puisse réaliser une authentification valide (fichier pg_hba.conf).

cd /opt
pg_basebackup --host=batman --user=streamer \
 --pgdata=robin --wal-method=stream --checkpoint=fast

touch robin/standby.signal
pg_ctl start -D robin

Un autre outil existe pour contrôler l’état d’une instance en scannant le contenu du fichier PGDATA/global/pg_control, notamment pour savoir si notre serveur est primaire ou secondaire et s’il réplique les journaux de transactions :

pg_controldata -D robin

# pg_control version number: 1201
# Catalog version number: 201909212
# Database system identifier: 6771436906102136159
# Database cluster state: in archive recovery
# Latest checkpoint location: 0/A000098
# Latest checkpoint's REDO location: 0/A000060
# Latest checkpoint's REDO WAL file: 00000001000000000000000A
# wal_level setting: replica
# wal_log_hints setting: on
# WAL block size: 8192
# Data page checksum version: 0

La bascule

À présent, mettons de la forme à notre incident.

Vous revenez de pause déjeûner aux alentours de 13:30 et le service support est alerté depuis midi de la perte d’un composant réseau sur votre datacenter principal. Toute la charge a basculé et les services web sont redirigées correctement… Pas de bol, les frontaux remontent des erreurs et la navigation est en mode dégradé : l’instance secondaire est en lecture seule, et l’on vous attendait pour corriger le tir !

Ni une ni deux, un accès au serveur robin et une commande solutionnent le problème :

pg_ctl promote -D robin

# FATAL: terminating walreceiver process due to administrator command
# LOG: invalid record length at 0/A000148: wanted 24, got 0
# LOG: redo done at 0/A000110
# LOG: selected new timeline ID: 2
# LOG: archive recovery complete
# LOG: database system is ready to accept connections

L’instance robin est donc promue, elle acceptera toutes les demandes d’écriture en contrepartie d’une nouvelle ligne de temps (timeline) dédiée aux futures transactions.

Je passe la scène des grandes accolades et chaleureux compliments qui n’auront jamais lieu car les équipes ont déjà d’autres chats à fouetter ; après tout, soyez réaliste, vous n’avez exécuté qu’une seule commande ! Autant dire, vous prenez votre pause, et alors que coule votre café, vous apprenez par l’intermédiaire du delivery manager que le client rencontre des dégradations de performance sur son backoffice depuis la perte du nœud batman. Mais, de quoi parle-t-il ?

Et l’architecture globale vous revient en mémoire. Une goûte perle votre front : l’instance secondaire est utilisée pour répartir la charge de lecture entre chaque nœud à l’aide de l’attribut de préférence target_session_attrs (documentation) et aucun mécanisme d’éviction en cas de split-brain ou de VIP flottante n’ont été déployés sur vos serveurs…

Synchronisation

L’urgence impose d’intervenir sur les chaînes de connexion pour réduire le risque de modification sur la mauvaise timeline. Vous recommandez à l’équipe support de retirer l’IP batman de tout ce qui s’apparente à un fichier settings_db.xml :

postgresql://app@batman,robin/gotham?target_session_attrs=read-write
# devient
postgresql://app@robin/gotham?target_session_attrs=read-write

Les performances ne sont bien évidemment pas meilleures, mais tout risque de perte de données lié au split-brain est écarté. Le timing est parfait, car au même moment, l’équipe système vous informe que l’intervention au datacenter a permis la remise en réseau des serveurs, toujours actifs.

Votre rôle consiste donc à rétablir la synchronisation entre batman et robin pour accomplir leur mission de répartition de charge. La première méthode disponible réside dans le duo gagnant pg_start/stop_backup() et rsync pour réaliser à la main une sauvegarde physique différentielle.

Première méthode

Puisque la sauvegarde exclusive est annoncée obsolète depuis la version 9.6, nous déclarerons le début d’une sauvegarde concurrente sur l’instance primaire robin à l’aide de la commande suivante et nous maintiendrons la connexion :

SELECT pg_start_backup('rsync the batman', true, false);
-- pg_start_backup
-- -----------------
-- 0/15000028

Sur le nœud batman, on peut alors transférer les données avec l’option --whole-file de la commande rsync pour réduire le risque de corruption des fichiers de données :

cd /opt
pg_ctl stop -D batman
rsync robin:/opt/robin/ batman --archive --checksum --whole-file

À l’issue de cette copie victorieuse, n’oubliez pas de lancer la commande pg_stop_backup() sur l’instance primaire pour finaliser la sauvegarde et la rendre valide.

SELECT labelfile FROM pg_stop_backup(false) \gx
-- -[ RECORD 1 ]-------------------------------------------------------------
-- labelfile | START WAL LOCATION: 0/15000028 (file 000000020000000000000015)+
-- | CHECKPOINT LOCATION: 0/15000060 +
-- | BACKUP METHOD: streamed +
-- | BACKUP FROM: master +
-- | START TIME: 2019-12-17 16:21:21 CET +
-- | LABEL: rsync the batman +
-- | START TIMELINE: 2 +

La dernière étape devient bordélique, mais n’ayez crainte, ça ne dure pas longtemps. Les commandes sont à exécuter sur l’instance secondaire batman et s’assurent notamment que l’instance redémarre avec les bons paramètres de réplication, dont primary_conninfo et les fichiers standby.signal et backup_label.

sed -i -e 's/batman/robin/g' batman/postgresql.auto.conf

rsync robin:/opt/robin/pg_wal/ batman/pg_wal \
 --archive --checksum --whole-file

# récupération des instructions backup_label présentes dans 
# le fichier .backup généré par la commande pg_stop_backup()
grep -iv ^stop batman/pg_wal/000000020000000000000015.00000028.backup \
 > batman/backup_label

rm batman/postmaster.pid
touch batman/standby.signal

pg_ctl start -D batman
# LOG: entering standby mode
# LOG: restored log file "00000002.history" from archive
# LOG: restored log file "000000020000000000000015" from archive
# LOG: redo starts at 0/15000028
# LOG: consistent recovery state reached at 0/15000138
# LOG: database system is ready to accept read only connections
# LOG: invalid record length at 0/16000148: wanted 24, got 0
# LOG: started streaming WAL from primary at 0/16000000 on timeline 2

L’état intermédiaire de notre cluster peut être visualisé comme suit. On constate que la zone d’archivage (batcave) réside donc sur le même serveur que l’instance nouvellement primaire robin et pourrait être un risque en cas de surincident. De manière générale, il est recommandé d’externaliser systématiquement les archives et les sauvegardes !

Vous y conviendrez, cette étape était particulièrement coton pour l’envisager dans une situation passablement stressante. Voyons ensemble l’autre solution plus adaptée à notre scénario : la commande pg_rewind.

Deuxième méthode

La situation reste inchangée, i.e. l’instance batman est primaire sur une ancienne timeline et doit être resynchronisée avec robin pour obtenir toutes les modifications réalisées depuis sa promotion.

Comme suggéré dans la documentation, le compte de réplication streamer doit disposer des droits d’exécution sur certaines fontions internes pour utiliser l’outil pg_rewind correctement :

\connect postgres

GRANT EXECUTE ON
 function pg_ls_dir(text, boolean, boolean) TO streamer;
GRANT EXECUTE ON
 function pg_stat_file(text, boolean) TO streamer;
GRANT EXECUTE ON
 function pg_read_binary_file(text) TO streamer;
GRANT EXECUTE ON
 function pg_read_binary_file(text, bigint, bigint, boolean) TO streamer;

Sur le serveur batman, l’instance doit être arrêtée avant de lancer la synchronisation et le contenu de la zone d’archivage batcave doit être copié manuellement vers le répertoire de récupération pg_wal ; il s’agit de reproduire l’instruction restore_command que ne peut pas exécuter l’instance lorsqu’elle est éteinte.

pg_ctl stop -D batman
rsync robin:/opt/batcave/ batman/pg_wal \
 --archive --checksum --whole-file

pg_rewind -D batman \
 --source-server="host=robin user=streamer dbname=postgres"
# pg_rewind: servers diverged at WAL location 0/8000060 on timeline 1
# pg_rewind: rewinding from last common checkpoint at 0/7000060 on timeline 1
# pg_rewind: Done!

Le résultat de la commande pg_rewind nous informe que batman est revenu à la position de sa timeline au moment de la promotion de robin. Cette opération repose sur un format étendu des journaux de transactions, désactivé par défaut. Les plus attentifs auront constaté le paramètre wal_log_hints=on(documentation) dans le fichier postgresql.auto.conf en début d’article, qui est l’un des prérequis de l’outil pg_rewind.

pg_rewind requires that the target server either has the wal_log_hints option enabled in postgresql.conf or data checksums enabled when the cluster was initialized with initdb. Neither of these are currently on by default. full_page_writes must also be set to on, but is enabled by default.

Pour certains au fond de la salle, cette opération correspond à l’instruction FLASHBACK DATABASE sur un moteur Oracle Database lorsque l’on souhaite reconstruire une instance Dataguard.

La dernière étape consiste à modifier la chaîne primary_conninfo et ajouter le fichier standby.signal avant de démarrer l’instance batman :

sed -i -e 's/batman/robin/g' batman/postgresql.auto.conf
touch batman/standby.signal

pg_ctl start -D batman
# LOG: entering standby mode
# LOG: restored log file "00000002.history" from archive
# LOG: restored log file "000000010000000000000007" from archive
# LOG: redo starts at 0/7000028
# LOG: restored log file "000000020000000000000008" from archive
# LOG: started streaming WAL from primary at 0/9000000 on timeline 2
# LOG: consistent recovery state reached at 0/904B5C8

Inversion des rôles

Cette opération permet la remise en place des rôles à leur état nominal. Ainsi, batman reprendra le contrôle et robin deviendra son second. Les étapes sont relativement simples :

Arrêter proprement l’instance robin pour écrire les caches sur disque, notamment les dernières transactions dans les journaux mais également, pour envoyer toutes les modifications à travers le flux de réplication vers batman ;

pg_ctl stop -D robin

Contrôler optionnellement que les positions sont identiques entre les deux instances ;

pg_controldata -D robin | grep -iE "(cluster state|checkpoint location)"
# Database cluster state: shut down
# Latest checkpoint location: 0/A000028

pg_controldata -D batman | grep -iE "(cluster state|checkpoint location)"
# Database cluster state: in archive recovery
# Latest checkpoint location: 0/A000028

Promouvoir la nouvelle instance primaire batman ;

pg_ctl promote -D batman
# LOG: received promote request
# LOG: redo done at 0/A000028
# LOG: selected new timeline ID: 3
# LOG: archive recovery complete
# LOG: restored log file "00000002.history" from archive
# LOG: database system is ready to accept connections

Configurer robin en instance secondaire et la démarrer.

touch robin/standby.signal
pg_ctl start -D robin
# LOG: restored log file "00000003.history" from archive
# LOG: entering standby mode
# LOG: restored log file "00000003.history" from archive
# LOG: restored log file "00000003000000000000000A" from archive
# LOG: restored log file "00000002.history" from archive
# LOG: consistent recovery state reached at 0/A0000A0
# LOG: redo starts at 0/A0000A0
# LOG: database system is ready to accept read only connections
# LOG: started streaming WAL from primary at 0/B000000 on timeline 3

Depuis la version 12, le paramètre recovery_target_timeline est défini sur la valeur latest par défaut, ce qui permet à l’instance secondaire de détecter le saut de timeline provoqué par une promotion et de raccrocher correctement les transactions à répliquer avant de se connecter en streaming à l’instance primaire.

Conclusion

L’architecture proposée répond à plusieurs problématiques assez fréquentes mais présente un certain nombre d’inconvénients. À travers cet article, nous avons parcouru l’ensemble des outils disponibles nativement avec PostgreSQL.

Comme rappelé précédemment, il est fortement conseillé de décentraliser la zone d’archivage sur un système de fichiers redondé pour se prévenir de l’absence d’un nœud. Le diagramme suivant présenterait alors le moins de risque possible tout en assurant un niveau de service acceptable, avec un minimum d’actions en cas de bascule :

La détection de panne et la bascule automatique sont des thématiques récurrentes lorsque l’on exprime un besoin de haute-disponibilité. Durant l’année 2019, une série d’outils tiers ont assis leur réputation avec notamment patroni de Zalando qui propose intelligemment l’usage de pg_rewind dans son fonctionnement.

Construire une instance standby avec pgBackRest

Florent Jardin — Thu, 07 Nov 2019 16:00:00 +0200

Pour cette démonstration, j’utilise le système Debian et dispose de deux instances en version 12, d’un serveur de sauvegarde et du paquet pgbackrest pour mettre en place une réplication et observer les nouveautés concernant la disparition du fichier recovery.conf.

Pour faciliter le transfert des WAL et des sauvegardes PITR, j’ajoute un compte utilisateur pgbr sur le serveur de sauvegarde, accessible à partir des deux instances avec un partage de clé SSH. (Conseil : toujours externaliser les sauvegardes de bases de données sur un système et un stockage indépendant de l’infrastructure de production PostgreSQL…)

sudo useradd -s /bin/bash -md /etc/pgbackrest pgbr
sudo mv /etc/pgbackrest.conf /etc/pgbackrest/
sudo chown pgbr: /etc/pgbackrest/pgbackrest.conf \
 /var/log/pgbackrest /var/lib/pgbackrest

La réplication par flux (streaming) est assurée par un compte dédié nommé streamer, autorisé à se connecter sur les instances PostgreSQL du sous-réseau grâce à l’ajout d’une entrée dans le fichier pg_hba.conf.

sudo -u postgres createuser --replication --pwprompt streamer

# pg_hba.conf
# Allow replication connections from trusted subnet, by a user with the
# replication privilege.
host replication streamer 10.1.0.0/28 md5

Le fichier .pgpass est déposé sur chaque serveur pour le compte postgres, afin d’assurer la connexion du compte streamer sans saisie de mot de passe.

Dans ce scénario, les archives générées par l’instance primaire seront déplacées sur le serveur de sauvegarde et l’instance standby les consultera au besoin. La planification des sauvegardes sera sous la responsabilité de l’utilisateur pgbr avec une administration distante. La configuration fine se découpe dans les fichiers suivants.

# /etc/pgbackrest/bkp1.conf
[lab]
pg1-host=lab1
pg2-host=lab2
pg1-host-user=postgres
pg2-host-user=postgres
pg1-path=/var/lib/postgresql/12/lab1
pg2-path=/var/lib/postgresql/12/lab2
pg1-host-config=/etc/pgbackrest/lab1.conf
pg2-host-config=/etc/pgbackrest/lab2.conf

[global]
start-fast=y
log-level-console=info
repo1-retention-full=2
repo1-path=/var/lib/pgbackrest

# /etc/pgbackrest/lab1.conf
[lab]
pg1-path=/var/lib/postgresql/12/lab1

[global]
repo1-host=bkp1
repo1-host-user=pgbr

# /etc/pgbackrest/lab2.conf
[lab]
pg1-path=/var/lib/postgresql/12/lab2
recovery-option=recovery_target_timeline=latest
recovery-option=primary_conninfo=host=lab1 port=5432 user=streamer

[global]
repo1-host=bkp1
repo1-host-user=pgbr

Avant de pouvoir créer la stanza, il est nécessaire de démarrer l’instance secondaire en mode standby ; il suffit de positionner un fichier standby.signal dans le répertoire de données et de redémarrer l’instance :

sudo pg_ctlcluster stop 12 lab2
sudo -u postgres touch /var/lib/postgresql/12/lab1/standby.signal
sudo pg_ctlcluster start 12 lab2

À partir de ce moment, et même si les deux instances ne partagent pas les mêmes données, je peux créer la stanza avec l’outil pgbackrest sur mon serveur de sauvegarde avec l’utilisateur dédié.

sudo -u pgbr pgbackrest stanza-create \
 --stanza=lab --config=/etc/pgbackrest/bkp1.conf

Dès ce moment, mon instance, consciente de l’espace de stockage distant, peut envoyer ses archives de WAL via la commande archive-push de pgbackrest. Un redémarrage est requis pour activer le mode archive.

ALTER SYSTEM SET archive_mode = on;
ALTER SYSTEM SET archive_command =
 'pgbackrest archive-push %p --stanza=lab --config=/etc/pgbackrest/lab1.conf';

Et pour finir, une première sauvegarde complète peut être lancée sur le serveur de sauvegarde pour assurer la construction de l’instance standby.

sudo -u pgbr pgbackrest backup --stanza=lab --config=/etc/pgbackrest/bkp1.conf
sudo -u pgbr pgbackrest info

# stanza: lab
# status: ok
# cipher: none
#
# db (current)
# wal archive min/max (12-1): 000000010000000000000008/000000010000000000000008
#
# full backup: 20191107-103443F
# timestamp start/stop: 2019-11-07 10:34:43 / 2019-11-07 10:35:09
# wal start/stop: 000000010000000000000008 / 000000010000000000000008
# database size: 23.5MB, backup size: 23.5MB
# repository size: 2.8MB, repository backup size: 2.8MB

La sauvegarde de l’instance primaire peut être restaurée sur la seconde instance avec les options --delta et --type=standby pour écraser les fichiers erronés et ajouter le descripteur standby.signal dans le répertoire de données. pgBackRest se charge de configurer les options de réplication dans le fichier postgresql.auto.conf

sudo pg_ctlcluster stop 12 lab2
sudo -u postgres pgbackrest restore --stanza=lab \
 --delta --type=standby --config=/etc/pgbackrest/lab2.conf
sudo pg_ctlcluster start 12 lab2

Tadaa ! Une connexion est alors établie entre les deux nœuds et l’on constate que l’utilisateur streamer rejoue en asynchrone les transactions de l’instance primaire vers l’instance standby.

select * from pg_stat_replication;

-- -[ RECORD 1 ]----+------------------------------
-- pid | 8893
-- usesysid | 16384
-- usename | streamer
-- application_name | 12/lab2
-- client_addr | 10.1.0.1
-- client_hostname |
-- client_port | 38820
-- backend_start | 2019-11-07 10:50:22.424464+00
-- backend_xmin |
-- state | streaming
-- sent_lsn | 0/A000060
-- write_lsn | 0/A000060
-- flush_lsn | 0/A000060
-- replay_lsn | 0/A000060
-- write_lag | 00:00:00.001095
-- flush_lag | 00:00:00.004415
-- replay_lag | 00:00:00.004696
-- sync_priority | 0
-- sync_state | async
-- reply_time | 2019-11-07 12:39:59.595595+00

Pour la rédaction de cet article, je n’ai pas véritablement utilisé trois serveurs, mais bien un seul en réalité. L’astuce pour faire tourner deux instances sur le même port 5432 consiste à ajouter des IP virtuelles sur l’interface du serveur et de faire résoudre les noms de machines par le fichier /etc/hosts local.

sudo ip add add 10.1.0.1/28 dev ens6
sudo ip add add 10.1.0.2/28 dev ens6
sudo ip add add 10.1.0.3/28 dev ens6

Les instances doivent ensuite être installées/configurées avec les bons paramètres listen_addresses et unix_socket_directories comme suivent :

sudo apt-get install -y postgresql-common
sudo vim /etc/postgresql-common/createcluster.conf
sudo apt-get install -y postgresql-12

sudo -u postgres mkdir -p /var/run/postgresql/lab{1,2}
sudo pg_createcluster 12 lab1 \
 --pgoption listen_addresses='10.1.0.1' --pgoption port=5432 \
 --pgoption unix_socket_directories=/var/run/postgresql/lab1
sudo pg_createcluster 12 lab2 \
 --pgoption listen_addresses='10.1.0.2' --pgoption port=5432 \
 --pgoption unix_socket_directories=/var/run/postgresql/lab2

sudo pg_ctlcluster 12 lab1 start
sudo pg_ctlcluster 12 lab2 start

Quelques ajustements de droits sur le répertoire /tmp/pgbackrest pour les fichiers de verrous (paramètre --lock-path) et le tour est joué !