🔝 Retour au Sommaire
Dans le contexte de la haute disponibilité PostgreSQL, la réplication permet de maintenir des copies de vos données sur plusieurs serveurs. Mais toutes les réplications ne fonctionnent pas de la même manière. La principale distinction réside dans le moment où les données sont considérées comme "sauvegardées" : immédiatement sur tous les serveurs (synchrone) ou d'abord sur le serveur principal puis propagées aux autres (asynchrone).
Ce chapitre vous aidera à comprendre les différences fondamentales entre ces deux approches et à choisir celle qui convient le mieux à vos besoins.
Avant d'aborder les différences, rappelons brièvement le principe de la réplication dans PostgreSQL :
- Serveur Primary (Primaire) : Le serveur principal qui accepte les écritures
- Serveur Standby (Secondaire) : Un ou plusieurs serveurs qui reçoivent une copie des données
- WAL (Write-Ahead Log) : Le journal des modifications qui est envoyé du Primary vers les Standby
La réplication permet de :
- Protéger contre la perte de données (disaster recovery)
- Distribuer la charge de lecture sur plusieurs serveurs
- Assurer la continuité de service en cas de panne
Dans la réplication asynchrone (le mode par défaut de PostgreSQL) :
- Une transaction est validée (COMMIT) sur le serveur Primary
- PostgreSQL confirme immédiatement au client que la transaction est réussie
- Les modifications sont ensuite envoyées aux serveurs Standby en arrière-plan
- Les Standby appliquent les modifications dès qu'ils les reçoivent
Client → Primary → Confirmation immédiate ✓
↓
Standby (plus tard)
🚀 Performance maximale
- Aucune attente pour les clients
- Les transactions sont aussi rapides que sur un serveur standalone
- Idéal pour les applications à fort trafic
🌍 Tolérance à la latence réseau
- Fonctionne bien même avec des Standby géographiquement éloignés
- Pas d'impact si le réseau est lent ou instable
💪 Résilience
- Si un Standby tombe en panne, le Primary continue de fonctionner normalement
- Pas de point de défaillance unique (SPOF) lié à la réplication
C'est le principal compromis : si le serveur Primary tombe en panne avant que les modifications n'aient été envoyées aux Standby, ces données sont perdues.
Exemple concret :
10:00:00 - Transaction validée sur le Primary
10:00:01 - Confirmation envoyée au client ✓
10:00:02 - PANNE du Primary avant envoi aux Standby ⚡
→ Les données de cette transaction sont perdues
📊 Décalage temporel (Replication Lag)
Les serveurs Standby peuvent être "en retard" par rapport au Primary :
- Quelques millisecondes en conditions normales
- Plusieurs secondes voire minutes en cas de charge élevée ou problème réseau
- Les lectures sur les Standby peuvent retourner des données obsolètes
La réplication asynchrone est recommandée pour :
- Applications web grand public où la performance prime
- Analytics et reporting où un léger décalage est acceptable
- Réplication géographique entre datacenters distants
- Disaster Recovery où l'objectif est surtout la protection contre une panne majeure
- Budget limité (pas besoin de matériel réseau haute performance)
Dans la réplication synchrone :
- Une transaction est validée (COMMIT) sur le serveur Primary
- PostgreSQL attend que les modifications soient reçues par au moins un serveur Standby
- Seulement après confirmation du Standby, PostgreSQL confirme au client
- Les données sont garanties présentes sur au moins deux serveurs
Client → Primary → Attente → Standby confirme ✓
↓ ↑
└─── Envoi WAL ────┘
↓
Confirmation au client ✓
🛡️ Protection maximale contre la perte de données
Les données validées sont garanties d'exister sur au moins deux serveurs :
- Même si le Primary tombe en panne, aucune transaction validée n'est perdue
- Le Standby possède exactement les mêmes données que le Primary au moment de la panne
📍 Cohérence stricte
- Vous savez avec certitude que vos données sont dupliquées
- RPO (Recovery Point Objective) = 0 : aucune perte de données
⚖️ Conformité réglementaire
Certains secteurs (bancaire, santé, industrie) exigent une protection maximale des données. La réplication synchrone peut aider à répondre à ces exigences.
🐌 Impact sur les performances
Chaque transaction d'écriture est plus lente car elle doit attendre :
- La transmission réseau vers le Standby
- La réception et l'accusé de réception du Standby
Ordre de grandeur :
- Réseau local (LAN) : +1 à 5 ms par transaction
- Réseau distant (WAN) : +50 à 200 ms ou plus
Pour une application qui fait 100 écritures par seconde, cela peut représenter un impact significatif.
🌐 Sensibilité à la latence réseau
Plus le Standby est éloigné, plus l'impact est fort :
- Réplication entre deux serveurs dans le même datacenter : viable
- Réplication entre deux continents : très problématique
⚡ Point de défaillance
Si le Standby synchrone tombe en panne :
- Le Primary attend qu'il revienne (mode par défaut)
- Toutes les écritures sont bloquées
- Il faut reconfigurer manuellement pour continuer
Mitigation : PostgreSQL permet de configurer plusieurs Standby synchrones avec des priorités différentes.
La réplication synchrone est recommandée pour :
- Applications financières (transactions bancaires, paiements)
- Données critiques où aucune perte n'est acceptable
- Systèmes de santé (dossiers médicaux)
- E-commerce (commandes, paiements)
- Infrastructure réseau fiable avec faible latence
| Critère | Asynchrone | Synchrone |
|---|---|---|
| Performance | ⭐⭐⭐⭐⭐ Excellente | ⭐⭐⭐ Bonne (impact latence) |
| Protection données | ⭐⭐⭐ Bonne (risque de perte) | ⭐⭐⭐⭐⭐ Excellente (aucune perte) |
| Latence réseau | ⭐⭐⭐⭐⭐ Très tolérant | ⭐⭐ Sensible |
| Réplication distante | ⭐⭐⭐⭐⭐ Idéal | ⭐⭐ Difficile |
| Complexité | ⭐⭐⭐⭐ Simple | ⭐⭐⭐ Moyenne |
| Disponibilité | ⭐⭐⭐⭐⭐ Continue | ⭐⭐⭐ Dépend du Standby |
| RPO | Quelques secondes/minutes | 0 (aucune perte) |
| RTO | Quelques secondes/minutes | Quelques secondes/minutes |
PostgreSQL offre des options intermédiaires pour équilibrer performance et fiabilité :
Le Primary attend que le Standby ait écrit les WAL dans son cache OS (mémoire), mais sans attendre le fsync sur disque. Plus rapide que on (qui exige le fsync), mais avec une nuance :
Trade-off :
- Protection contre une panne du processus PostgreSQL sur le standby (les pages en cache OS survivent)
⚠️ Pas de protection contre un crash du système d'exploitation ou une panne matérielle du standby juste après réception (les pages en cache OS non flushées sont alors perdues)- Performance meilleure que
oncar pas d'attente du fsync distant
Le Primary attend que le Standby ait fsync les WAL sur son disque physique. C'est le mode synchrone "classique".
Trade-off :
- Garantie de durabilité même en cas de crash OS / panne matérielle du standby
- Plus lent que
remote_write(ajoute le temps de fsync sur le standby)
Le Primary attend que le Standby ait appliqué les WAL à sa base — donc les modifications sont visibles en lecture sur le standby au moment où le primary répond au client.
Trade-off :
- Garantie "read-after-write" stricte sur le standby (utile pour le load balancing en lecture)
- Performance encore plus impactée (ajoute le temps de replay au temps réseau et au fsync)
PostgreSQL permet de configurer un quorum : attendre la confirmation de N serveurs parmi M Standby.
Exemple : synchronous_standby_names = 'ANY 2 (standby1, standby2, standby3)'
- Le Primary attend la confirmation de 2 serveurs parmi 3
- Meilleure tolérance aux pannes qu'avec un seul Standby synchrone
- Flexibilité accrue
💡 Le quorum est détaillé dans la section 17.6.2. Quorum-based commit.
1. Quelle est la criticité de vos données ?
- Critique (finance, santé) → Synchrone
- Importante mais récupérable → Asynchrone
2. Quel est votre RPO (Recovery Point Objective) ?
- RPO = 0 (aucune perte acceptable) → Synchrone
- RPO = quelques secondes/minutes → Asynchrone
3. Quelle est votre latence réseau vers les Standby ?
- < 5 ms (même datacenter) → Synchrone viable
-
50 ms (géographiquement distant) → Asynchrone recommandé
4. Quel est votre volume d'écritures ?
- Très élevé → Asynchrone (pour préserver les performances)
- Modéré → Synchrone (impact acceptable)
5. Avez-vous une infrastructure réseau fiable ?
- Oui (datacenter de qualité) → Synchrone possible
- Non (réseau public, instable) → Asynchrone préférable
De nombreuses organisations utilisent une combinaison des deux :
Primary
├── Standby 1 (Synchrone, même datacenter)
└── Standby 2 (Asynchrone, datacenter distant)
Avantages :
- Protection maximale contre la perte de données (Standby synchrone local)
- Protection géographique contre un désastre (Standby asynchrone distant)
- Performance acceptable (latence locale faible)
Sur le serveur Primary, aucune configuration spéciale n'est nécessaire. La réplication est asynchrone par défaut.
-- Vérifier le mode actuel
SHOW synchronous_commit;
-- Résultat : on (mais asynchrone si aucun standby synchrone n'est configuré)Sur le serveur Primary, dans postgresql.conf :
# Définir les serveurs Standby synchrones
synchronous_standby_names = 'standby1'
# Quorum ANY : attendre la confirmation de N parmi M (les plus rapides)
synchronous_standby_names = 'ANY 1 (standby1, standby2)'
# FIRST N : attendre les N premiers de la liste par ordre de priorité
# (ici, les 2 standbys nommés, donc les deux doivent confirmer)
synchronous_standby_names = 'FIRST 2 (standby1, standby2)'Sur le serveur Standby, dans postgresql.conf :
# Définir le nom de l'application (doit correspondre à synchronous_standby_names)
primary_conninfo = 'host=primary_ip port=5432 user=replicator application_name=standby1'-- Voir l'état de la réplication
-- sync_state peut prendre 4 valeurs :
-- 'async' : asynchrone (n'est pas dans synchronous_standby_names)
-- 'potential' : pourra devenir sync (FIRST N, rang > N tant qu'un sync est OK)
-- 'sync' : synchrone classique (FIRST N)
-- 'quorum' : participe à un quorum (ANY N)
SELECT
application_name,
state,
sync_state,
sync_priority
FROM pg_stat_replication;Quelle que soit votre configuration, surveillez ces indicateurs :
1. Replication Lag (décalage)
SELECT
application_name,
pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes,
extract(epoch from (now() - pg_last_xact_replay_timestamp()))::int AS lag_seconds
FROM pg_stat_replication;Objectif : Maintenir un lag < 1 seconde en conditions normales
2. WAL Sender State
- Vérifier que le processus
wal senderest actif - Surveiller l'utilisation réseau
1. Durée des commits et transactions bloquées par SyncRep
Sous réplication synchrone, le COMMIT bloque en attente de la confirmation du standby. Pour mesurer cet impact :
-- Transactions actuellement en attente de SyncRep (côté primary)
SELECT pid, usename, state, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE wait_event = 'SyncRep';
-- Avec pg_stat_statements (extension à activer), comparer total_exec_time
-- avant/après activation de la réplication synchrone pour mesurer l'impact :
SELECT query, calls, mean_exec_time, max_exec_time
FROM pg_stat_statements
WHERE query ILIKE '%INSERT%' OR query ILIKE '%UPDATE%'
ORDER BY mean_exec_time DESC
LIMIT 10; ℹ️ Le paramètre
track_commit_timestamp(souvent évoqué dans ce contexte) sert en réalité à enregistrer l'horodatage de chaque transaction commitée pour des cas comme la résolution de conflits en réplication logique ou la fonctionpg_xact_commit_timestamp(). Il ne mesure pas l'attente sous SyncRep.
Objectif : Durée acceptable selon vos SLA (< 10 ms idéalement)
2. État des Standby synchrones
SELECT sync_state, state
FROM pg_stat_replication
WHERE sync_state = 'sync'; Objectif : Toujours au moins un Standby en état 'sync' et 'streaming'
Problème : L'impact sur les temps de réponse peut être significatif et dégrader l'expérience utilisateur.
Solution : Testez en environnement de préproduction et surveillez les métriques de latence.
Problème : La latence réseau élevée rend toutes les écritures très lentes.
Solution : Utilisez l'asynchrone pour les Standby distants et le synchrone uniquement pour les Standby locaux.
Problème : Si le seul Standby synchrone tombe, toutes les écritures sont bloquées.
Solution : Configurez plusieurs Standby avec priorités ou utilisez un quorum.
Problème : Sous-estimer la valeur de la réplication asynchrone.
Réalité : L'asynchrone offre une excellente protection contre la plupart des pannes. Le lag est généralement de quelques millisecondes en conditions normales.
Besoins :
- Performance essentielle (temps de réponse < 100 ms)
- Protection contre les pannes
- Tolérance à la perte de quelques transactions en cas de catastrophe
Recommandation : Asynchrone avec un Standby local + un Standby distant
Justification :
- Les utilisateurs ne doivent pas subir de ralentissement
- La perte de quelques secondes de transactions est acceptable en cas de catastrophe majeure
- Le Standby local permet une promotion rapide en cas de panne
Besoins :
- Aucune perte de transaction acceptable
- Conformité réglementaire stricte
- Performance secondaire (mais importante)
Recommandation : Synchrone avec quorum (2 Standby locaux)
Justification :
- RPO = 0 exigé
- Le quorum évite le point de défaillance unique
- Infrastructure réseau de qualité bancaire avec latence < 2 ms
Besoins :
- Gros volumes de données
- Tolérance au décalage (quelques minutes)
- Réplication vers plusieurs datacenters
Recommandation : Asynchrone exclusivement
Justification :
- La nature analytique tolère un décalage
- Les performances d'écriture sont critiques (imports massifs)
- Réplication géographique impossible en synchrone
Besoins :
- Balance entre performance et fiabilité
- Clients avec différents SLA
- Architecture multi-région
Recommandation : Hybride - Synchrone local + Asynchrone distant
Justification :
- Protection maximale avec impact performance minimal (synchrone local)
- Disaster recovery géographique (asynchrone distant)
- Flexibilité selon les clients (certains peuvent choisir asynchrone uniquement)
Le choix entre réplication synchrone et asynchrone n'est pas binaire. Il dépend de votre contexte spécifique :
Choisissez l'asynchrone si :
- La performance est votre priorité numéro 1
- Vous avez une infrastructure réseau étendue
- Vous acceptez un RPO de quelques secondes
- Vous avez un fort volume d'écritures
Choisissez la synchrone si :
- La perte de données est inacceptable (RPO = 0)
- Vous avez une infrastructure réseau fiable et rapide
- Vos contraintes réglementaires l'exigent
- Votre volume d'écritures est modéré
Choisissez l'hybride si :
- Vous voulez le meilleur des deux mondes
- Vous avez plusieurs datacenters
- Vous avez besoin de protection locale ET géographique
Points clés à retenir :
- L'asynchrone n'est pas "dangereux" : Le lag est généralement minimal et offre une excellente protection
- La synchrone a un coût : Impact performance et complexité opérationnelle
- Testez avant de décider : Mesurez l'impact réel dans votre environnement
- Surveillez en continu : Les métriques de réplication doivent faire partie de votre monitoring
- Évoluez progressivement : Commencez asynchrone, puis passez au synchrone si nécessaire
La réplication PostgreSQL est un outil puissant et flexible. Comprendre les trade-offs vous permet de faire le choix optimal pour votre architecture.
Prochaine section : 17.6.2. Quorum-based commit - Approfondir les configurations de quorum pour la haute disponibilité
Ressources complémentaires :
- Documentation officielle : High Availability, Load Balancing, and Replication
- Section 17.2 : Réplication Physique (Streaming Replication)
- Section 17.3 : Réplication Logique