Comment fonctionne la réplication dans PostgreSQL ?

Question

Accepted Answer

**Replication** copie les données d'une base de données **primaire** vers un ou plusieurs serveurs **replica** (standby) — pour la haute disponibilité (basculement si la primaire tombe en panne) et la mise à l'échelle en lecture (distribuer les requêtes de lecture). PostgreSQL utilise principalement la **streaming replication** (physique) basée sur le write-ahead log (WAL).

## Streaming (physical) replication

```text
Primary  ──(streams WAL: the write-ahead log of changes)──▶  Replica(s)
  ✓ The primary handles all WRITES
  ✓ Replicas continuously apply the primary's WAL → stay in sync (near-real-time)
  ✓ Replicas can serve READ queries ("hot standby") → scale reads
```

La primaire diffuse son **WAL** (write-ahead log — un enregistrement de chaque modification) aux replicas, qui l'appliquent pour rester synchronisées. Les replicas sont des copies en lecture seule qui peuvent servir les requêtes de lecture.

## Les bénéfices : HA et mise à l'échelle en lecture

```text
HIGH AVAILABILITY → if the primary fails, a replica can be PROMOTED to primary (failover)
  → minimal downtime, no data loss (with synchronous replication)
READ SCALING → route read-only queries to replicas → offload the primary
  → handle more read traffic (great for read-heavy workloads)
BACKUPS → take backups from a replica without loading the primary
```

## Réplication synchrone vs asynchrone

```text
ASYNCHRONOUS (default) → the primary commits without waiting for replicas
  ✓ faster writes (no wait)   ✗ a tiny window of potential data loss on failover
SYNCHRONOUS → the primary waits for a replica to confirm before committing
  ✓ no data loss on failover  ✗ slower writes (waits for the replica)
→ Choose based on the durability vs performance trade-off.
```

## Logical replication (un modèle différent)

```text
LOGICAL replication → replicates specific TABLES/changes (not the whole cluster), based
on a publish/subscribe model. Enables: selective replication, cross-version, and
replicating to different schemas → good for migrations, integrations, partial replication.
```

## Haute disponibilité en pratique

```text
Tools like Patroni, repmgr, or cloud-managed Postgres automate FAILOVER (detecting
primary failure and promoting a replica) → near-automatic high availability.
A load balancer / connection router directs writes to the primary, reads to replicas.
```

## Pourquoi c'est important

La réplication est importante pour construire des déploiements PostgreSQL **hautement disponibles et évolutifs**, donc la comprendre est une connaissance précieuse de haut niveau pour l'architecture de base de données en production.

Les deux bénéfices principaux sont critiques pour les applications sérieuses : **haute disponibilité** (si la base de données primaire tombe en panne, un replica peut être promu pour prendre le relais, minimisant l'indisponibilité — essentiel pour les systèmes qui doivent rester disponibles) et **mise à l'échelle en lecture** (router les requêtes en lecture seule vers les replicas allège la primaire, permettant au système de gérer beaucoup plus de trafic en lecture — valable pour les charges de travail lourdes en lecture).

Comprendre la **streaming replication** (la primaire diffusant son WAL aux replicas qui restent synchronisés et peuvent servir les lectures) est la fondation.

Connaître le compromis **synchrone vs asynchrone** est important : asynchrone (par défaut — écritures plus rapides mais une petite fenêtre de perte de données potentielle lors du basculement) contre synchrone (aucune perte de données mais écritures plus lentes) — une décision de durabilité contre performance affectant la fiabilité.

Comprendre la **logical replication** (répliquer des tables spécifiques via pub/sub, utile pour les migrations, les versions croisées, et la réplication partielle/sélective) élargit les options.

Savoir que l'**outillage HA** (Patroni, repmgr, Postgres cloud géré) automatise le basculement, et que le routage lecture/écriture dirige le trafic de manière appropriée, est une connaissance architecturale pratique.

Puisque la haute disponibilité et la scalabilité sont des exigences essentielles pour les systèmes de base de données en production, et puisque la réplication (avec son basculement HA, sa mise à l'échelle en lecture, le compromis durabilité sync/async, et la logical replication pour la flexibilité) est le mécanisme principal que PostgreSQL fournit pour cela, comprendre la réplication est une connaissance de haut niveau importante pour concevoir des déploiements Postgres fiables et évolutifs — une préoccupation fréquemment pertinente pour les systèmes en production et un sujet démontrant la compréhension de la disponibilité et de la mise à l'échelle des bases de données qui est attendue pour les rôles senior de base de données/backend.