Chapitre 2 : Réplication de base de données PostgreSQL
Introduction
La réplication de base de données PostgreSQL est un mécanisme permettant de maintenir
des copies d'une base de données sur plusieurs serveurs. Cette technique est très utile pour
améliorer la disponibilité, la tolérance aux pannes et la répartition des charges de travail. Il
existe plusieurs types de réplication dans PostgreSQL, les plus courants étant la réplication
asynchrone et la réplication synchronisée.
1. Concepts de base
Avant de commencer à configurer la réplication, il est important de comprendre quelques
concepts clés :
Master (ou primaire) : C'est le serveur principal où toutes les écritures de la base de
données sont effectuées.
Standby (ou secondaire) : C'est une ou plusieurs copies de la base de données du
serveur primaire. Elles reçoivent les données modifiées depuis le primaire, mais
n'effectuent pas d'écritures.
2. Types de réplication
Il existe deux principaux types de réplication dans PostgreSQL :
Réplication synchrone : Les données doivent être écrites à la fois sur le primaire et
sur le secondaire avant que la transaction ne soit considérée comme validée. Ce type
garantit une cohérence stricte, mais il peut être plus lent.
Réplication asynchrone : Les écritures sont d'abord effectuées sur le serveur
primaire, puis répliquées sur le secondaire de manière asynchrone. Cela peut offrir de
meilleures performances, mais il existe un risque que les données sur le secondaire ne
soient pas immédiatement à jour par rapport au primaire.
3. Configuration d'une réplication en streaming (asynchrone)
Voici les étapes détaillées pour configurer une réplication en streaming entre un serveur
primaire (master) et un serveur secondaire (standby).
A. Pré-requis
Avoir deux serveurs PostgreSQL installés (un primaire et un secondaire).
Avoir les droits d'administrateur sur ces serveurs.
Utiliser la même version de PostgreSQL sur les deux serveurs.
B. Configuration du serveur primaire
1. Activer la réplication dans PostgreSQL : Modifiez le fichier postgresql.conf du
serveur primaire :
o wal_level : Définit le niveau de journalisation des transactions pour la
réplication. Il doit être défini sur replica ou logical.
o max_wal_senders : Spécifie le nombre maximum de processus qui peuvent
envoyer des données WAL (Write-Ahead Logs) au serveur secondaire. Il doit
être réglé sur un nombre supérieur à 0.
o wal_keep_size : Spécifie la taille du fichier WAL à conserver sur le serveur
primaire, afin d'éviter sa suppression avant qu'il ne soit répliqué sur le
secondaire.
Exemple de configuration dans postgresql.conf :
wal_level = replica
max_wal_senders = 10
wal_keep_size = 16MB
2. Activer l'accès réseau pour la réplication : Modifiez le fichier pg_hba.conf pour
autoriser les connexions de réplication depuis le serveur secondaire. Ajoutez une ligne
du type :
3. host replication all <IP_du_serveur_secondaire>/32 md5
4. Redémarrer PostgreSQL : Après avoir modifié ces fichiers, redémarrez PostgreSQL
sur le serveur primaire pour appliquer les changements :
5. sudo systemctl restart postgresql
C. Préparation du serveur secondaire
1. Créer une copie de la base de données primaire : Il faut d'abord préparer la base de
données secondaire avec une copie exacte de la base de données primaire. Cela se fait
généralement via la commande pg_basebackup.
Exécutez cette commande depuis le serveur secondaire :
pg_basebackup -h <IP_du_serveur_primaire> -D
/var/lib/postgresql/12/main -U replication_user -P --wal-
method=stream
Cette commande crée une copie de la base de données primaire dans le répertoire de
données du serveur secondaire.
2. Configurer le fichier recovery.conf : Le fichier recovery.conf sur le serveur
secondaire permet de définir comment il se connecte au serveur primaire pour
récupérer les WAL.
Créez le fichier recovery.conf dans le répertoire de données du serveur secondaire
avec ce contenu :
standby_mode = on
primary_conninfo = 'host=<IP_du_serveur_primaire> port=5432
user=replication_user password=<mot_de_passe>'
trigger_file = '/tmp/postgresql.trigger.5432'
o primary_conninfo contient les informations pour se connecter au serveur
primaire.
o trigger_file est un fichier utilisé pour basculer le rôle du serveur secondaire
en primaire en cas de panne (optionnel).
3. Redémarrer PostgreSQL sur le serveur secondaire : Redémarrez PostgreSQL sur
le serveur secondaire pour que la réplication commence :
4. sudo systemctl restart postgresql
D. Vérification de la réplication
Vous pouvez vérifier l'état de la réplication avec la commande suivante sur le serveur
primaire :
SELECT * FROM pg_stat_replication;
Cela affiche les informations sur les processus de réplication actifs.
4. Gestion de la réplication
Surveillance : Surveillez régulièrement les fichiers WAL et l'état de la réplication. Si
vous utilisez la réplication asynchrone, vérifiez que les données ne sont pas trop en
retard sur le serveur secondaire.
Failover et switchover : Si le serveur primaire tombe en panne, vous pouvez
promouvoir le serveur secondaire pour qu'il devienne le primaire en créant le fichier
de basculement (trigger_file). Dans un environnement de production, un outil
comme repmgr ou Patroni peut être utilisé pour automatiser ce processus.
5. Conclusion
La réplication PostgreSQL est un mécanisme puissant pour améliorer la disponibilité et la
tolérance aux pannes de votre base de données. Une fois la réplication en streaming
configurée, les serveurs secondaires sont maintenus à jour avec les modifications apportées à
la base de données principale. La configuration nécessite des ajustements au niveau du fichier
postgresql.conf, du fichier pg_hba.conf, et de l'utilisation de la commande
pg_basebackup pour créer des copies de la base de données. Vous pouvez également
configurer un basculement en cas de panne pour assurer la continuité du service.
Pour plus de détails veuillez lire cet article :
https://www.postgresql.org/docs/16/runtime-config-replication.html
