Réplication physique – Haute disponibilité avec PostgreSQL

Bonne lecture et bon apprentissage !
Junior TSAFACK – 20/08/2026
⏱️ Temps de lecture estimé : 12 minutes

---

La réplication est un élément clé pour assurer la haute disponibilité et la sécurité des données. PostgreSQL propose plusieurs types de réplication. Ce cours se concentre sur la réplication physique, la plus utilisée pour la reprise après sinistre (DR) et les environnements de production critiques.

---

Qu’est-ce que la réplication physique ?

La réplication physique consiste à copier les fichiers de données (et les WAL) du serveur principal (master) vers un ou plusieurs serveurs secondaires (slaves/standbys). Le slave est une copie binaire identique du master.

Caractéristiques

• Identique au master : structure, données, index, tout est copié.
• Read-Only : le slave est en lecture seule (Hot Standby).
• Basée sur les WAL : les modifications sont répliquées via les journaux de transactions.
• Deux modes : synchrone ou asynchrone.

Cas d’usage

Cas d’usage	Description
Haute disponibilité	Si le master tombe, le slave prend le relais (failover).
Reprise après sinistre (DR)	Un slave dans un autre datacenter pour la continuité d’activité.
Reporting / Lecture	Décharger le master des requêtes de reporting lourdes.
Sauvegarde	Faire les sauvegardes sur le slave pour ne pas impacter le master.

---

Types de réplication physique

Asynchrone (par défaut)

Le master envoie les WAL au slave sans attendre sa confirmation.

Avantages :

• Pas de latence en écriture sur le master.
• Performances optimales.

Inconvénients :

• Risque de perte de données en cas de crash du master (si les WAL n’ont pas été transmis).

Synchrone

Le master attend que le slave confirme la réception des WAL avant de valider la transaction.

Avantages :

• Zéro perte de données (RPO = 0).

Inconvénients :

• Latence en écriture (dépend du réseau).
• Si le slave est lent ou indisponible, le master peut être bloqué.

---

Modes de transmission des WAL

Mode	Description
Log shipping	Envoi des fichiers WAL complets (archivage).
Streaming replication	Envoi des enregistrements WAL en continu (flux).

Streaming replication est le mode recommandé car il est plus réactif (les données sont répliquées presque en temps réel) et il est compatible avec le Hot Standby (le slave peut être interrogé en lecture).

---

Architecture d’une réplication physique

┌─────────────────────────────────────────────────────────────────┐
│                          MASTER                                 │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                    PostgreSQL                            │   │
│  │  ┌─────────┐  ┌──────────┐  ┌───────────────────────┐   │   │
│  │  │  WAL    │  │  WAL     │  │  pg_stat_replication   │   │   │
│  │  │  Buffer │──│  Sender  │──│  (monitoring)          │   │   │
│  │  └─────────┘  └──────────┘  └───────────────────────┘   │   │
│  └──────────────────────────────────────────────────────────┘   │
│                           │                                     │
│                           │ Streaming WAL                       │
│                           ▼                                     │
└─────────────────────────────────────────────────────────────────┘
                            │
                            │ Réseau
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                           SLAVE                                 │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                    PostgreSQL                            │   │
│  │  ┌─────────┐  ┌──────────┐  ┌───────────────────────┐   │   │
│  │  │  WAL    │  │  WAL     │  │  pg_stat_wal_receiver │   │   │
│  │  │  Receiver│──│  Replay  │──│  (monitoring)          │   │   │
│  │  └─────────┘  └──────────┘  └───────────────────────┘   │   │
│  └──────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ⚠️  Mode : Hot Standby (lecture seule)                         │
└─────────────────────────────────────────────────────────────────┘

---

Configuration de la réplication

Environnement de test

Serveur	Rôle	Adresse IP
pg-master	Master	192.168.60.3
pg-slave	Slave	192.168.60.4

Étape 1 : Configuration du Master

1.1 Créer l’utilisateur de réplication

CREATE USER replication REPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTED PASSWORD 'replication_password';

Explications :

• REPLICATION : droit de se connecter en mode réplication.
• LOGIN : droit de se connecter.
• CONNECTION LIMIT 1 : une seule connexion pour la réplication.
• ENCRYPTED PASSWORD : mot de passe chiffré.

1.2 Configurer pg_hba.conf

Ajouter une ligne pour autoriser l’utilisateur replication à se connecter depuis le slave.

# Ajouter dans /etc/postgresql/16/main/pg_hba.conf
host    replication     replication     192.168.60.4/32         scram-sha-256
# ou en MD5 selon votre configuration
host    replication     replication     192.168.60.0/24         md5

💡 Bon à savoir : Le CIDR /32 autorise une seule IP. Utilisez /24 pour autoriser tout un sous-réseau.

1.3 Configurer postgresql.conf

Modifier les paramètres suivants :

/etc/postgresql/16/main/postgresql.conf

# Écouter toutes les interfaces (ou l'IP du master)
listen_addresses = '*'

# Niveau de journalisation pour la réplication
wal_level = replica

# Nombre maximum de processus d'envoi WAL (pour les slaves)
max_wal_senders = 10

# Nombre de fichiers WAL conservés sur le master
wal_keep_segments = 100

# Hot Standby (le slave peut être interrogé en lecture)
hot_standby = on

# Mode de réplication synchrone (asynchrone par défaut)
# synchronous_commit = on  # Décommentez pour le mode synchrone
# synchronous_standby_names = 'pg-slave'  # Nom du slave

Paramètres expliqués :

Paramètre	Valeur	Description
listen_addresses	'*'	Accepte les connexions de toutes les interfaces.
wal_level	replica	Nécessaire pour la réplication.
max_wal_senders	10	Nombre de slaves simultanés (ajustez selon vos besoins).
wal_keep_segments	100	Conserve 100 fichiers WAL (16 Mo chacun = 1,6 Go).
hot_standby	on	Permet les requêtes en lecture sur le slave.

1.4 Redémarrer le master

sudo systemctl restart postgresql

1.5 Vérifier la configuration

-- Vérifier les paramètres
SHOW wal_level;
SHOW max_wal_senders;
SHOW wal_keep_segments;
SHOW hot_standby;

-- Vérifier l'utilisateur de réplication
SELECT rolname, rolreplication FROM pg_roles WHERE rolname = 'replication';

---

Étape 2 : Configuration du Slave

2.1 Arrêter PostgreSQL sur le slave

sudo systemctl stop postgresql

2.2 Supprimer les données existantes

sudo rm -rf /var/lib/postgresql/16/main/*

⚠️ Attention : Cette opération supprime toutes les données du slave. Assurez-vous qu’il s’agit bien d’une nouvelle installation.

2.3 Copier les données du master avec pg_basebackup

sudo -u postgres pg_basebackup \
    -h 192.168.60.3 \
    -D /var/lib/postgresql/16/main/ \
    -P -U replication \
    --wal-method=fetch \
    -v

Options expliquées :

Option	Description
-h	Adresse IP du master.
-D	Répertoire de destination (datas du slave).
-P	Affiche la progression.
-U	Utilisateur de réplication.
--wal-method=fetch	Copie les WALs nécessaires.
-v	Mode verbeux.

💡 Bon à savoir : pg_basebackup peut être long selon la taille de la base.

2.4 Créer le fichier recovery.conf

PostgreSQL 12 et versions ultérieures utilisent standby.signal et postgresql.auto.conf plutôt que recovery.conf. Voici la méthode moderne :

Méthode 1 : Fichier recovery.conf (PostgreSQL 11 et antérieurs)

sudo -u postgres vim /var/lib/postgresql/16/main/recovery.conf

standby_mode = 'on'
primary_conninfo = 'host=192.168.60.3 port=5432 user=replication password=replication_password'
trigger_file = '/tmp/MasterNow'
restore_command = 'cp /var/lib/postgresql/16/main/pg_wal/%f %p'

Méthode 2 : PostgreSQL 12+ (recommandée)

# Créer le fichier standby.signal
sudo -u postgres touch /var/lib/postgresql/16/main/standby.signal

# Configurer les paramètres de connexion
sudo -u postgres vim /var/lib/postgresql/16/main/postgresql.auto.conf

primary_conninfo = 'host=192.168.60.3 port=5432 user=replication password=replication_password'
primary_slot_name = 'standby_slot'  # Optionnel, si vous utilisez des replication slots

# Définir le trigger_file (pour le failover)
sudo -u postgres vim /var/lib/postgresql/16/main/postgresql.conf
# Ajouter ou modifier :
# trigger_file = '/tmp/MasterNow'

2.5 Démarrer le slave

sudo systemctl start postgresql

2.6 Vérifier la réplication

Sur le master :

SELECT * FROM pg_stat_replication;

Sur le slave :

SELECT * FROM pg_stat_wal_receiver;

---

Test de la réplication

Étape 1 : Créer des données sur le master

-- Sur le master (192.168.60.3)
CREATE DATABASE test_replication;
\c test_replication
CREATE TABLE test (id SERIAL PRIMARY KEY, nom TEXT);
INSERT INTO test (nom) VALUES ('Donnée 1'), ('Donnée 2'), ('Donnée 3');
SELECT * FROM test;

Étape 2 : Vérifier sur le slave

-- Sur le slave (192.168.60.4)
\c test_replication
SELECT * FROM test;
-- Résultat : 1, Donnée 1 | 2, Donnée 2 | 3, Donnée 3

Étape 3 : Test d’écriture sur le slave (doit échouer)

-- Sur le slave (lecture seule)
INSERT INTO test (nom) VALUES ('Donnée 4');
-- Réponse : ERROR: cannot execute INSERT in a read-only transaction

---

Failover manuel

Étape 1 : Simuler la panne du master

# Sur le master (192.168.60.3)
sudo systemctl stop postgresql

Étape 2 : Promouvoir le slave en master

Avec trigger_file (méthode recovery.conf) :

# Sur le slave (192.168.60.4)
sudo touch /tmp/MasterNow
# PostgreSQL détecte le fichier et promeut le slave en master

Avec pg_ctl promote (PostgreSQL 12+) :

sudo -u postgres pg_ctl promote -D /var/lib/postgresql/16/main/

Avec pg_promote (fonction SQL) :

SELECT pg_promote();

Étape 3 : Vérifier que le slave est devenu master

-- Sur l'ancien slave (devenu master)
SELECT pg_is_in_recovery();
-- Résultat : f (false) = n'est plus en réplication

-- Tester une écriture
INSERT INTO test (nom) VALUES ('Donnée après failover');
SELECT * FROM test;

---

Resynchronisation de l’ancien master

Étape 1 : Arrêter l’ancien master

# Sur l'ancien master (192.168.60.3)
sudo systemctl stop postgresql

Étape 2 : Supprimer les données

sudo rm -rf /var/lib/postgresql/16/main/*

Étape 3 : Copier les données du nouveau master

# Sur l'ancien master (maintenant slave)
sudo -u postgres pg_basebackup \
    -h 192.168.60.4 \
    -D /var/lib/postgresql/16/main/ \
    -P -U replication \
    --wal-method=fetch \
    -v

Étape 4 : Créer le fichier standby.signal (ou recovery.conf)

# PostgreSQL 12+
sudo -u postgres touch /var/lib/postgresql/16/main/standby.signal

# Configurer la connexion vers le nouveau master
sudo -u postgres vim /var/lib/postgresql/16/main/postgresql.auto.conf

primary_conninfo = 'host=192.168.60.4 port=5432 user=replication password=replication_password'

Étape 5 : Démarrer l’ancien master (maintenant slave)

sudo systemctl start postgresql

Étape 6 : Vérifier la réplication

-- Sur le nouveau master (192.168.60.4)
SELECT * FROM pg_stat_replication;

---

Bonnes pratiques

Pratique	Description
Utiliser le streaming replication	Plus réactif que le log shipping.
Activer le Hot Standby	Permet d’utiliser le slave pour des requêtes de lecture.
Surveiller la réplication	Utilisez pg_stat_replication et pg_stat_wal_receiver.
Tester le failover régulièrement	Simulez une panne pour vérifier la procédure.
Utiliser un réseau rapide	La réplication dépend de la bande passante réseau.
Sauvegarder sur le slave	Déchargez le master en faisant les sauvegardes sur le slave.
Utiliser des replication slots	Évite la suppression prématurée des WAL sur le master.
Configurer la réplication synchrone	Pour le Zéro RPO (pour les transactions critiques).
Documenter la procédure de failover	Assurez-vous que l’équipe sait comment réagir en cas de panne.

---

Replication slots (PostgreSQL 9.4+)

Les replication slots garantissent que les WAL nécessaires au slave sont conservés sur le master, même si le slave est déconnecté.

Création d’un slot

-- Sur le master
SELECT pg_create_physical_replication_slot('standby_slot');

Utilisation dans la configuration du slave

Dans postgresql.auto.conf :

primary_conninfo = 'host=192.168.60.3 port=5432 user=replication password=replication_password'
primary_slot_name = 'standby_slot'

Surveillance des slots

SELECT * FROM pg_replication_slots;

Suppression d’un slot

SELECT pg_drop_replication_slot('standby_slot');

---

Réplication synchrone

Configuration

Sur le master, dans postgresql.conf :

synchronous_commit = on
synchronous_standby_names = 'pg-slave'

Vérification

-- Sur le master
SHOW synchronous_commit;
SHOW synchronous_standby_names;
SELECT * FROM pg_stat_replication WHERE sync_state = 'sync';

⚠️ Attention : En mode synchrone, si le slave est indisponible, le master attend indéfiniment ou jusqu’au timeout.

---

Commandes récapitulatives

Action	Commande
Créer l’utilisateur de réplication	CREATE USER replication REPLICATION LOGIN PASSWORD '...';
Démarrer PostgreSQL	sudo systemctl start postgresql
Arrêter PostgreSQL	sudo systemctl stop postgresql
Reload PostgreSQL	sudo systemctl reload postgresql
Copier les données du master	pg_basebackup -h master -D /var/lib/postgresql/16/main/ -P -U replication
Promouvoir un slave	sudo -u postgres pg_ctl promote -D /var/lib/postgresql/16/main/
Vérifier la réplication (master)	SELECT * FROM pg_stat_replication;
Vérifier la réplication (slave)	SELECT * FROM pg_stat_wal_receiver;
Créer un replication slot	SELECT pg_create_physical_replication_slot('slot_name');
Voir les replication slots	SELECT * FROM pg_replication_slots;
Voir l’état de la réplication	SELECT pg_is_in_recovery();

---

Prochain chapitre

Vous savez maintenant configurer une réplication physique manuelle. Dans le prochain cours, nous aborderons la réplication avancée avec REPMGR, qui automatise le failover et la gestion des clusters PostgreSQL.

👉 Cours 13 : REPMGR – Gestion automatisée de la réplication

---

Junior TSAFACK – 20/08/2026