Patterns de haute disponibilité PostgreSQL

SECTION 1

Introduction

La haute disponibilité mesure la capacité d'un système à rester opérationnel lorsqu'une partie de son infrastructure défaille. Pour une base PostgreSQL, elle passe avant tout par l'élimination des points uniques de défaillance, ces composants dont la panne suffit à mettre tout le service à l'arrêt.

Elle suppose une surveillance continue de la santé des serveurs, un mécanisme de basculement automatique fiable et, lorsque c'est possible, une répartition géographique des ressources. Il faut la distinguer de la répartition de charge, où plusieurs machines coopèrent pour servir les mêmes données ; les deux approches renforcent toutefois la résilience du système et se combinent souvent dans les architectures de production.

SECTION 2

Les fondamentaux : RTO, RPO et élimination des points uniques de défaillance

### Mesurer la disponibilité : RTO, RPO, MTTR

Avant de choisir un outil, il faut fixer des objectifs chiffrés. Le RTO (Recovery Time Objective) borne la durée maximale d'indisponibilité acceptable après un incident ; le RPO (Recovery Point Objective) borne la quantité de données qu'on accepte de perdre, exprimée en temps. Une base facturation avec un RPO de zéro seconde n'a pas les mêmes exigences architecturales qu'un entrepôt analytique tolérant quelques minutes de perte. Le MTTR (Mean Time To Recovery) complète le tableau en mesurant la durée moyenne réellement observée pour revenir en service.

### Répartition de charge : complémentaire, pas substituable

Un cluster en répartition de charge distribue les requêtes entre plusieurs nœuds pour absorber le trafic, mais ne garantit rien en cas de panne d'un nœud si aucun mécanisme de bascule n'existe derrière. La haute disponibilité et la scalabilité horizontale répondent à des problèmes différents : la première protège contre l'indisponibilité, la seconde contre la saturation. Une architecture mature combine les deux, avec des rôles clairement définis entre nœuds primaires, secondaires synchrones et répliques de lecture.

SECTION 3

Les stratégies de réplication PostgreSQL

### Réplication en flux (streaming replication)

La réplication en flux est le pilier historique de la haute disponibilité PostgreSQL. Un serveur de secours (standby) se connecte au serveur primaire et reçoit en continu ses enregistrements WAL (Write-Ahead Log), ce qui crée une réplique quasi identique avec un décalage minimal, souvent de l'ordre de quelques millisecondes en réplication synchrone. En cas de défaillance du primaire, le standby dispose de toutes les données nécessaires pour prendre le relais rapidement, sans reconstruction longue.

### Réplication logique : granularité et flexibilité

La réplication logique offre davantage de granularité que la réplication physique. Elle permet de ne répliquer que des tables choisies, d'appliquer des transformations à la volée, et autorise, en option, des écritures directes sur la base secondaire. Elle rend également possible la réplication d'un même serveur secondaire à partir de plusieurs sources, un atout pour les architectures distribuées, les migrations à froid ou la consolidation de plusieurs environnements vers un entrepôt analytique unique.

SECTION 4

Patroni : l'orchestration déclarative du cluster

### Le magasin clé-valeur comme source de vérité

Patroni est un framework de gestion de cluster qui détermine l'état d'un cluster PostgreSQL grâce à l'intégration d'un magasin clé-valeur distribué, etcd, Consul ou ZooKeeper selon les déploiements. Ce magasin fait office de source de vérité partagée : chaque nœud y consulte et y publie son état, ce qui évite toute ambiguïté sur l'identité du primaire à un instant donné. Patroni assure une surveillance continue et permet un basculement manuel ou planifié, utile lors des opérations de maintenance.

### Watchdog Linux et prévention du split-brain

Le risque majeur d'un cluster mal orchestré est le split-brain, où deux nœuds se croiraient tous deux primaires et accepteraient des écritures divergentes. Patroni s'appuie sur le watchdog Linux pour forcer le redémarrage d'un nœud qui perdrait le contact avec le magasin de configuration au-delà d'un délai critique, garantissant qu'un nœud isolé du réseau ne puisse jamais continuer à écrire en croyant être toujours primaire.

SECTION 5

PgPool-II : pooling de connexions et répartition des lectures

### La fonctionnalité Watchdog depuis la version 3.2

PgPool-II est un gestionnaire de pool de connexions placé devant le cluster PostgreSQL. Depuis la version 3.2, il implémente sa propre fonctionnalité Watchdog, qui lui permet de fonctionner en haute disponibilité à plusieurs instances et d'éviter qu'il devienne lui-même un point unique de défaillance, un piège fréquent des architectures qui négligent la résilience de leur couche de proxy.

### Répartition de charge en lecture et gain de performance

PgPool-II réutilise les connexions existantes pour réduire la charge d'établissement de session sur PostgreSQL, un poste souvent sous-estimé sur les workloads à fort trafic. Il répartit également les requêtes de lecture entre le primaire et les répliques, améliorant à la fois la disponibilité et les performances en lecture sans changement applicatif.

@cite:postgresql-bonnes-pratiques-de-performance

SECTION 6

PostgreSQL Automatic Failover (PAF) et l'écosystème Kubernetes

### Réplication synchrone et intégrité des données avec Pacemaker et Corosync

PAF (PostgreSQL Automatic Failover) répond à un besoin précis : éviter toute perte de données lors d'un basculement. Pour cela, il repose sur une réplication synchrone, qui garantit que les données sont bien écrites sur le secondaire avant d'être validées côté client. Il s'appuie sur Pacemaker pour la gestion des ressources du cluster et Corosync pour la couche de communication et la détection des défaillances, une combinaison éprouvée dans les environnements bancaires et industriels où l'intégrité prime sur la latence de bascule.

### CloudNativePG et les opérateurs Kubernetes en 2026

Sur les plateformes Kubernetes, l'opérateur CloudNativePG s'est imposé comme l'approche de référence pour opérer PostgreSQL en cloud-native : il encapsule les mêmes principes (élection de primaire, réplication synchrone ou asynchrone configurable, basculement automatique) sous forme de ressources déclaratives, avec sauvegardes continues intégrées vers un stockage objet. Il ne remplace pas la compréhension des mécanismes sous-jacents décrits plus haut, mais en automatise l'exploitation au sein d'un cluster Kubernetes.

SECTION 7

Sauvegarde, observabilité et tests de bascule

### Une stratégie de sauvegarde qui complète, pas remplace, la réplication

La réplication protège contre la panne matérielle, pas contre l'erreur applicative ou la suppression accidentelle qui se propage instantanément vers toutes les répliques. Une politique de sauvegarde avec rétention à plusieurs niveaux, sauvegardes complètes régulières, archivage continu des WAL, tests de restauration périodiques, reste indispensable pour couvrir les scénarios que la haute disponibilité ne traite pas.

@cite:sauvegarde-et-restauration-cloud

### Vérifier la résilience réelle par des bascules contrôlées

Un mécanisme de failover jamais testé en conditions réelles est une hypothèse, pas une garantie. Les équipes matures programment des exercices de bascule contrôlée en environnement de préproduction, voire en production sur des créneaux définis, pour vérifier que le RTO annoncé correspond au RTO observé et que les applications clientes gèrent correctement la reconnexion.

@cite:chaos-engineering-bonnes-pratiques

SECTION 8

L'approche Adservio

Chez Adservio, nous considérons la haute disponibilité comme une exigence de conception, pas comme une option ajoutée après coup. Le choix entre réplication en flux ou logique, entre Patroni, PgPool-II, PAF ou un opérateur Kubernetes comme CloudNativePG, dépend toujours du niveau de tolérance à la perte de données, des objectifs de RTO/RPO et des contraintes réelles de l'infrastructure.

Notre conviction : une architecture résiliente se pense en amont, autour des points uniques de défaillance à éliminer, et se prouve par des tests de bascule réguliers plutôt que par une documentation théorique. Nous accompagnons vos équipes dans le choix et la mise en place de ces patterns, puis leur transférons la maîtrise pour maintenir durablement la disponibilité de leurs bases PostgreSQL.

FAQ

Questions fréquentes