Déployer un cluster PostgreSQL haute disponibilité avec Patroni, Etcd et HAProxy

Publié le 17/05/2025

Base de données
Haute disponibilité
Docker

La haute disponibilité est cruciale pour garantir l’accessibilité continue de vos bases de données en production. Dans ce guide, nous allons déployer un cluster PostgreSQL résilient en utilisant :

  • Patroni pour la gestion du cluster et du failover automatique
  • Etcd pour le consensus distribué
  • HAProxy comme point d’entrée unique pour vos applications

Cette stack est compatible Docker, Kubernetes et déploiement bare-metal.

Pourquoi choisir cette architecture ?

  • 🔁 Failover automatique du nœud leader
  • Réplication intégrée avec bascule automatique
  • ⚙️ Gestion simplifiée des rôles primary/replica
  • 🌐 Point d’entrée unique grâce à HAProxy
  • 🧩 Extensible avec des outils comme pgBackRest, PgBouncer, Prometheus, etc.

Prérequis

  • 3 machines (VM ou containers) sous Debian 12 ou Ubuntu 22.04
  • Docker & Docker Compose
  • Ports ouverts entre les nœuds : 5432, 8008, 2379
  • Un peu de patience 😅

Architecture cible

    +----------+        +----------+        +----------+
    | Node 1   |        | Node 2   |        | Node 3   |
    | Patroni  | <----> | Patroni  | <----> | Patroni  |
    | PostgreSQL|       | PostgreSQL|       | PostgreSQL|
    +----------+        +----------+        +----------+
        \                  |                /
         \               etcd cluster      /
          \__________  HAProxy  __________/
                      (Client Entry)

Étape 1 : Déploiement du cluster Etcd

Créez un docker-compose.yml pour Etcd (3 instances) :

version: '3'
services:
  etcd1:
    image: quay.io/coreos/etcd:latest
    environment:
      - ETCD_NAME=etcd1
      - ETCD_INITIAL_CLUSTER=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      - ETCD_INITIAL_CLUSTER_STATE=new
      - ETCD_INITIAL_ADVERTISE_PEER_URLS=http://etcd1:2380
      - ETCD_ADVERTISE_CLIENT_URLS=http://etcd1:2379
      - ETCD_LISTEN_PEER_URLS=http://0.0.0.0:2380
      - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379
    ports:
      - "2379:2379"
    networks:
      - cluster

  etcd2:
    image: quay.io/coreos/etcd:latest
    environment:
      - ETCD_NAME=etcd2
      ...
  etcd3:
    image: quay.io/coreos/etcd:latest
    environment:
      - ETCD_NAME=etcd3
      ...
networks:
  cluster:

Étape 2 : Configuration de Patroni

Créez un fichier patroni.yml adapté à chaque nœud :

scope: pg-ha
name: node1

etcd:
  host: etcd1:2379

restapi:
  listen: 0.0.0.0:8008
  connect_address: node1:8008

postgresql:
  listen: 0.0.0.0:5432
  connect_address: node1:5432
  data_dir: /data/postgres
  authentication:
    superuser:
      username: postgres
      password: superpass
    replication:
      username: replicator
      password: replpass
  parameters:
    wal_level: replica
    hot_standby: "on"

Créez un service Docker par nœud avec ce fichier monté dans /etc/patroni.yml.


Étape 3 : Configuration de HAProxy

Sur une machine dédiée ou un 4e container :

frontend pgsql
  bind *:5432
  default_backend pgsql_nodes

backend pgsql_nodes
  option pgsql-check user postgres
  server node1 node1:5432 check port 8008
  server node2 node2:5432 check port 8008
  server node3 node3:5432 check port 8008

Lancement de la stack

docker compose up -d
  • Accédez à Patroni : http://<node-ip<:8008
  • HAProxy redirige les connexions vers le leader automatiquement

Test de bascule

  1. Stoppez le nœud leader :
docker stop patroni-node1
  1. Vérifiez que HAProxy redirige automatiquement vers un nouveau leader
  2. Redémarrez le nœud → il revient en tant que replica

Supervision & sauvegardes

  • 🔍 Intégrer Patroni Exporter ou PostgreSQL Exporter → Prometheus/Grafana
  • 💾 Ajoutez pgBackRest pour les sauvegardes automatisées et compressées
  • ⚙️ Utilisez PgBouncer pour le pooling de connexions

Avantages de Patroni

  • ✅ Compatible PostgreSQL 14, 15, 16
  • ✅ Basé sur etcd / Consul → stable
  • ✅ API REST simple pour l’intégration
  • ✅ Déploiement Docker/K8s/bare-metal

Alternatives

SolutionConsensusAuto-FailoverSimplicitéCloud-ready
Patronietcd✅ Oui⭐⭐⭐⭐✅ Oui
Stolonetcd✅ Oui⭐⭐⭐✅ Oui
Repmgr❌ Non⚠️ Scripté⭐⭐❌ Non
Citus HAInterne✅ Partiel⭐⭐⭐✅ Oui

Conclusion

Mettre en place une stack PostgreSQL haute disponibilité avec Patroni est un excellent compromis entre résilience, modernité et contrôle. Vous disposez maintenant d’une architecture fiable, compatible production, avec failover automatique, supervision, et extensibilité cloud-native.

Besoin d'aide sur ce sujet ?

Notre équipe d'experts est là pour vous accompagner dans vos projets.

Contactez-nous

Articles similaires qui pourraient vous intéresser