Guide étape par étape pour configurer la réplication en streaming PostgreSQL

La réplication en streaming est le mécanisme fondamental pour atteindre une haute disponibilité (HA) et une évolutivité en lecture dans les environnements PostgreSQL. En configurant un serveur primaire (maître) pour diffuser en continu les enregistrements du journal d'écriture anticipée (WAL) vers un ou plusieurs serveurs de secours (réplicas), vous assurez la synchronisation des données avec un décalage minimal.

Ce guide vous accompagne dans la mise en place de la réplication en streaming asynchrone à l'aide de pg_basebackup, pg_hba.conf et des fichiers de signal de secours. Vous obtiendrez une paire primaire-secours fonctionnelle et les vérifications nécessaires pour prouver qu'elle diffuse bien.

Prérequis et configuration de l'environnement

Avant de commencer, assurez-vous que les prérequis suivants sont remplis. Ce guide suppose deux serveurs, Primaire et Secours, exécutant la même version majeure de PostgreSQL (version 12 ou ultérieure recommandée).

Serveur	Rôle	Adresse IP (Exemple)
Primaire	Source de vérité	192.168.1.10
Secours	Réplica	192.168.1.11

• Utilisateur : Vous devez avoir un accès administratif (par exemple, sudo ou l'utilisateur système postgres) sur les deux serveurs.
• Réseau : Le serveur de secours doit pouvoir se connecter au serveur primaire sur le port PostgreSQL (5432 par défaut).

Étape 1 : Configurer le serveur primaire

Le serveur primaire doit être configuré pour générer et servir les fichiers WAL pour la réplication.

1.1 Modifier postgresql.conf

Modifiez le fichier de configuration principal. Sur les paquets Debian et Ubuntu, il se trouve souvent dans /etc/postgresql/<version>/main/postgresql.conf ; sur de nombreuses installations source ou conteneur, il se trouve dans le répertoire de données. Définissez ces paramètres :

# Autoriser les connexions depuis d'autres hôtes
listen_addresses = '*'

# Définir le niveau WAL sur 'replica' ou supérieur
wal_level = replica

# Nombre maximum de connexions simultanées depuis les serveurs de secours
max_wal_senders = 5 

# Contrôle le nombre de connexions de secours pouvant être actives simultanément
max_replication_slots = 5

# Permet les requêtes en lecture seule sur le serveur de secours
hot_standby = on

1.2 Créer un utilisateur de réplication dédié

Pour des raisons de sécurité, créez un utilisateur spécifique avec l'attribut REPLICATION. Cet utilisateur sera utilisé uniquement par le serveur de secours pour récupérer les enregistrements WAL.

# Se connecter à PostgreSQL
sudo -u postgres psql -c "CREATE ROLE replica_user WITH REPLICATION LOGIN PASSWORD 'utilisez-un-vrai-secret-ici';"

1.3 Mettre à jour l'authentification client (pg_hba.conf)

Autorisez l'utilisateur de réplication depuis l'adresse IP du serveur de secours à se connecter à la pseudo-base de données spéciale replication.

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replica_user    192.168.1.11/32         md5

1.4 Redémarrer le serveur primaire

Appliquez les modifications de configuration. Un redémarrage est l'option simple après avoir modifié listen_addresses ; si vous avez seulement modifié pg_hba.conf, un rechargement suffit.

sudo systemctl restart postgresql

Étape 2 : Préparer le serveur de secours

Avant de cloner les données, assurez-vous que le service PostgreSQL du serveur de secours est arrêté et que son répertoire de données existant est vidé.

2.1 Arrêter le service PostgreSQL du serveur de secours

sudo systemctl stop postgresql

2.2 Vider le répertoire de données

Attention : Cette étape supprime définitivement toutes les données actuellement dans le répertoire de données du serveur de secours. Confirmez le chemin avant exécution.

# Exemple de chemin pour PG 14
PG_DATA=/var/lib/postgresql/14/main

sudo rm -rf $PG_DATA/*

2.3 Cloner les données à l'aide de pg_basebackup

Utilisez pg_basebackup pour créer une copie exacte du répertoire de données du primaire. L'option -R est cruciale car elle génère automatiquement les fichiers de configuration nécessaires (standby.signal et primary_conninfo) pour la réplication en streaming (PostgreSQL 12+).

Exécutez cette commande sur le serveur de secours :

PG_DATA=/var/lib/postgresql/14/main

sudo -u postgres pg_basebackup -h 192.168.1.10 -D $PG_DATA -U replica_user -P -v -R

Option	Description
-h	Nom d'hôte ou adresse IP du serveur primaire.
-D	Chemin du répertoire de données local.
-U	Nom d'utilisateur de réplication (replica_user).
-P	Afficher la progression.
-v	Sortie verbose.
-R	Créer automatiquement un fichier de configuration de réplication.

Étape 3 : Configurer et démarrer le serveur de secours

3.1 Vérifier la configuration du serveur de secours

Si vous avez utilisé l'option -R à l'étape 2.3, pg_basebackup a créé un fichier standby.signal et renseigné le paramètre primary_conninfo, généralement dans un fichier de configuration généré nommé postgresql.auto.conf dans le répertoire de données.

Vérifiez le contenu de la chaîne primary_conninfo. Elle devrait ressembler à ceci (vérifiez dans $PG_DATA/postgresql.auto.conf) :

primary_conninfo = 'host=192.168.1.10 user=replica_user password=SuperSecurePassword123 application_name=standby_node'

Astuce : Assurez-vous que le mot de passe est inclus dans primary_conninfo ou que vous utilisez une authentification par certificat. Si vous utilisez pg_hba.conf avec trust ou cert, le mot de passe peut être omis.

3.2 Démarrer le service de secours

Étant donné que le fichier de signal requis (standby.signal) est présent dans le répertoire de données, le service démarrera en mode secours en lecture seule et tentera immédiatement de se connecter au primaire.

sudo systemctl start postgresql

Étape 4 : Vérifier la réplication en streaming

Après avoir démarré le serveur de secours, vous devez confirmer que la connexion est active et que la synchronisation des données a lieu.

4.1 Vérification sur le serveur primaire

Connectez-vous au serveur primaire et interrogez la vue pg_stat_replication. Vous devriez voir une ligne représentant la connexion du serveur de secours.

psql -c "SELECT client_addr, state, sync_state, sent_lsn, write_lsn, flush_lsn FROM pg_stat_replication;"

Sortie attendue (champs clés) :

• client_addr : Doit correspondre à l'IP du serveur de secours (par exemple, 192.168.1.11).
• state : Doit être streaming. S'il affiche startup ou catching up, attendez un moment. S'il affiche walsender en démarrage, vous êtes proche.
• sync_state : Doit être async (pour la réplication asynchrone standard).

4.2 Tester la synchronisation des données

Pour confirmer le flux de données, effectuez une modification sur le primaire et vérifiez immédiatement son existence sur le serveur de secours.

Sur le primaire :

CREATE TABLE replication_test (id serial primary key, message text);
INSERT INTO replication_test (message) VALUES ('Données synchronisées avec succès');

Sur le serveur de secours (lecture seule) :

-- Cela doit réussir sans erreur
psql -c "SELECT * FROM replication_test;"

Si les données sont visibles sur le serveur de secours, la réplication en streaming est configurée et active avec succès.

Bonnes pratiques et dépannage

Connexion persistante : Emplacements de réplication

Bien qu'optionnels, les emplacements de réplication sont fortement recommandés. Un emplacement de réplication garantit que le serveur primaire ne supprime pas prématurément les segments WAL nécessaires au serveur de secours, même si celui-ci se déconnecte temporairement.

Sur le primaire :

SELECT * FROM pg_create_physical_replication_slot('standby_slot_name');

Ensuite, définissez primary_slot_name sur le serveur de secours. Ne mettez pas le nom de l'emplacement dans primary_conninfo.

primary_conninfo = 'host=192.168.1.10 user=replica_user password=utilisez-un-vrai-secret-ici application_name=standby_node'
primary_slot_name = 'standby_slot_name'

Attention : Les emplacements de réplication nécessitent une surveillance attentive. Si un serveur de secours tombe en panne pendant une période prolongée, les fichiers WAL accumulés protégés par l'emplacement peuvent remplir rapidement l'espace disque du serveur primaire.

Dépannage des problèmes courants

Problème	Cause potentielle	Solution
Le serveur de secours ne peut pas se connecter	Pare-feu réseau, listen_addresses incorrect ou pg_hba.conf incorrect sur le primaire.	Vérifiez que le port 5432 est accessible ; confirmez que pg_hba.conf correspond à l'IP du serveur de secours et à l'utilisateur.
pg_basebackup échoue avec une erreur d'authentification	Mot de passe incorrect ou entrée d'hôte manquante dans pg_hba.conf.	Vérifiez le mot de passe de replica_user ; assurez-vous que la base de données primaire a été redémarrée après la modification de pg_hba.conf.
Le serveur de secours est en lecture seule	C'est le comportement attendu.	La présence de standby.signal force le serveur en mode récupération.

Prochaine étape

La mise en place de la réplication en streaming est une étape cruciale dans la construction d'une architecture PostgreSQL résiliente. En suivant ces étapes, vous avez configuré avec succès une paire primaire-secours qui assure une synchronisation continue des données, améliorant considérablement les capacités de haute disponibilité de votre système. La prochaine étape logique consiste à intégrer une solution de surveillance et un mécanisme de basculement (comme Patroni ou Repmgr) pour automatiser complètement la configuration HA.