Comment réaliser une haute disponibilité dans PostgreSQL ?

Question

Accepted Answer

**La haute disponibilité (HA)** signifie maintenir la base de données disponible même en cas de défaillances — par le biais de la **réplication** (réplicas de secours), du **basculement automatique** (promotion d'un replica quand le primaire tombe en panne) et d'une architecture appropriée. L'objectif : minimiser les temps d'arrêt et les pertes de données, puisque les pannes de base de données mettent toute l'application hors service.

## La base : réplication + basculement automatique

```text
Primary ──(streaming replication)──▶ Standby replica(s)

If the PRIMARY fails:
  → a STANDBY is automatically PROMOTED to become the new primary (FAILOVER)
  → the application reconnects to the new primary → minimal downtime
→ Without HA, a primary failure = total database outage = application down.
```

La réplication maintient les réplicas de secours synchronisés ; le **basculement automatique** détecte la défaillance du primaire et promeut un replica — transformant une panne totale en une brève interruption.

## Outils HA (automatisation du basculement)

```text
Patroni → the popular HA solution: manages failover, uses a consensus store (etcd/
  Consul/ZooKeeper) to coordinate, prevents split-brain
repmgr → replication and failover management
Managed Postgres (AWS RDS/Aurora, Cloud SQL, etc.) → built-in HA with automatic failover
→ These automate detection + promotion, which is hard to do safely by hand.
```

Le basculement manuel est lent et sujet aux erreurs, donc les outils HA (ou les services gérés) l'automatisent de manière sûre — y compris la prévention du **split-brain** (deux primaires acceptant des écritures, ce qui corrompt les données).

## Routage des connexions

```text
Applications need to find the CURRENT primary after a failover:
  → a load balancer / proxy (HAProxy, PgBouncer) or service discovery routes
    WRITES to the current primary and READS to replicas
  → after failover, routing updates to point to the new primary
```

## Considérations clés pour la HA

```text
✓ Synchronous replication → no data loss on failover (vs async's small loss window)
✓ Multiple replicas / multiple availability zones → survive zone failures
✓ Avoid SPLIT-BRAIN (two primaries) — consensus/fencing prevents it (critical for safety)
✓ Monitoring + health checks to detect failures quickly
✓ Test failover regularly (like backups, untested failover may not work)
→ Many teams use MANAGED Postgres for built-in, battle-tested HA.
```

## Pourquoi c'est important

La haute disponibilité est une connaissance importante pour l'exploitation des systèmes PostgreSQL **critiques pour la production**, car les pannes de base de données mettent l'application entière hors service (la base de données est souvent la dépendance la plus critique), donc comprendre comment maintenir Postgres disponible malgré les défaillances est une connaissance précieuse au niveau senior pour les systèmes fiables.

La base — **réplication plus basculement automatique** — transforme une défaillance de la base de données primaire (qui serait autrement une panne totale de l'application) en une brève interruption récupérable : les réplicas de secours restent synchronisés, et quand le primaire tombe en panne, un replica est automatiquement promu pour prendre la relève.

Comprendre les **outils HA** (Patroni — la solution populaire coordonnant le basculement via un magasin de consensus ; repmgr ; ou Postgres en cloud géré avec HA intégrée) est important car automatiser le basculement de manière sûre est difficile à faire à la main.

Connaître les **considérations clés** est critique : la **réplication synchrone** pour aucune perte de données lors du basculement, les **réplicas multiples dans les zones de disponibilité** pour survivre aux défaillances de zones, et surtout **éviter le split-brain** (empêcher deux primaires d'accepter simultanément des écritures, ce qui corrompt les données — un risque sérieux que le consensus/cloisonnement prévient).

Comprendre le **routage des connexions** (diriger l'application vers le primaire actuel après basculement, via des équilibreurs de charge/proxies) et que le basculement (comme les sauvegardes) doit être **testé** complète la connaissance pratique.

Savoir que de nombreuses équipes utilisent **Postgres géré** pour une HA éprouvée est également pertinent.

Puisque la disponibilité de la base de données est critique pour les systèmes de production (une panne paralyse tout), et puisque la réaliser exige de comprendre la réplication, le basculement automatique, la prévention du split-brain et le routage des connexions (ou l'utilisation de HA géré), comprendre la haute disponibilité de PostgreSQL est une connaissance importante au niveau senior pour architecturer des systèmes fiables et résilients — une préoccupation fréquemment critique pour les bases de données de production et un sujet démontrant la compréhension de la façon de construire une infrastructure de base de données qui survit aux défaillances, attendue pour les rôles senior de base de données/infrastructure.