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

La réplication en continu est le mécanisme fondamental pour atteindre une haute disponibilité (HA) et une scalabilité 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 secondaires (répliques), vous assurez la synchronisation des données avec un délai minimal.

Ce guide complet vous accompagne à travers les étapes essentielles requises pour établir une réplication en continu asynchrone robuste. Nous couvrons les modifications de configuration nécessaires sur les serveurs primaire et secondaire, en utilisant des fonctionnalités modernes de PostgreSQL comme pg_basebackup et les fichiers de signalisation pour une configuration simplifiée. Suivre ce tutoriel vous fournira une base fiable pour un fonctionnement PostgreSQL robuste.

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 Secondaire, exécutant la même version majeure de PostgreSQL (version 12 ou plus récente est recommandée).

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

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

Étape 1 : Configuration du serveur primaire

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

1.1 Modification de postgresql.conf

Modifiez le fichier de configuration principal, généralement situé dans le répertoire de données (par exemple, /etc/postgresql/14/main/postgresql.conf), et définissez les paramètres suivants :

# 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 secondaires
max_wal_senders = 5 

# Contrôle le nombre de connexions de réplication qui peuvent être actives simultanément
max_replication_slots = 5

# Requis pour les requêtes en lecture seule sur le secondaire (Hot Standby)
hot_standby = on

1.2 Création d'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 secondaire pour extraire les enregistrements WAL.

# Connexion à PostgreSQL
psql -c "CREATE USER replica_user REPLICATION ENCRYPTED PASSWORD 'SuperSecurePassword123';"

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

Autorisez l'utilisateur de réplication depuis l'adresse IP du serveur secondaire à 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émarrage du serveur primaire

Appliquez les modifications en redémarrant le service PostgreSQL :

sudo systemctl restart postgresql

Étape 2 : Préparation du serveur secondaire

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

2.1 Arrêt du service PostgreSQL du secondaire

sudo systemctl stop postgresql

2.2 Vidage du répertoire de données

Attention : Cette étape supprime définitivement toutes les données actuellement présentes dans le répertoire de données du secondaire. Confirmez le chemin avant l'exécution.

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

sudo rm -rf $PG_DATA/*

2.3 Clonage des 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 continu (PostgreSQL 12+).

Exécutez cette commande sur le serveur secondaire :

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/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 détaillée (verbeuse).
-R	Créer automatiquement un fichier de configuration de réplication.

Étape 3 : Configuration et démarrage du secondaire

3.1 Vérification de la configuration du secondaire

Si vous avez utilisé l'option -R à l'étape 2.3, pg_basebackup a créé un fichier standby.signal et rempli 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 à l'intérieur de $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 l'authentification par certificat. Si vous utilisez pg_hba.conf avec trust ou cert, le mot de passe peut être omis.

3.2 Démarrage du service secondaire

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

sudo systemctl start postgresql

Étape 4 : Vérification de la réplication en continu

Après le démarrage du secondaire, vous devez confirmer que la connexion est active et que la synchronisation des données est en cours.

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 secondaire.

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 secondaire (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 cours de démarrage, vous êtes proche.
• sync_state : Doit être async (pour la réplication asynchrone standard).

4.2 Test de la synchronisation des données

Pour confirmer le flux de données, exécutez une modification sur le primaire et vérifiez immédiatement son existence sur le secondaire.

Sur le primaire :

CREATE TABLE replication_test (id serial primary key, message text);
INSERT INTO replication_test (message) VALUES ('Data synchronized successfully');

Sur le secondaire (Lecture seule) :

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

Si les données sont visibles sur le secondaire, la réplication en continu est correctement configurée et active.

Meilleures pratiques et dépannage

Connexion persistante : Slots de réplication

Bien qu'optionnels, les slots de réplication sont fortement recommandés. Un slot de réplication garantit que le serveur primaire ne supprime pas prématurément les segments WAL nécessaires au secondaire, même si ce dernier se déconnecte temporairement.

Sur le primaire :

SELECT * FROM pg_create_physical_replication_slot('standby_slot_name');

Ensuite, mettez à jour le primary_conninfo sur le secondaire pour utiliser ce slot :

primary_conninfo = 'host=192.168.1.10 user=replica_user ... application_name=standby_node **slotname=standby_slot_name**'

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

Dépannage des problèmes courants

Problème	Cause potentielle	Solution
Le secondaire est bloqué en starting	Pare-feu réseau ou pg_hba.conf incorrect sur le primaire.	Vérifiez que le port 5432 est ouvert ; confirmez que l'entrée pg_hba.conf correspond à l'IP et à l'utilisateur du secondaire.
pg_basebackup échoue avec une erreur d'authentification	Mot de passe incorrect ou entrée 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 secondaire est en lecture seule	C'est le comportement attendu.	La présence de standby.signal force le serveur en mode de récupération.

Conclusion

La configuration de la réplication en continu est une étape cruciale dans la construction d'une architecture PostgreSQL résiliente. En suivant ces étapes, vous avez correctement configuré une paire primaire-secondaire 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 entièrement la configuration HA.