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
- Stoppez le nœud leader :
docker stop patroni-node1
- Vérifiez que HAProxy redirige automatiquement vers un nouveau leader
- Redémarrez le nœud → il revient en tant que replica
Supervision & sauvegardes
- 🔍 Intégrer
Patroni Exporter
ouPostgreSQL 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
Solution | Consensus | Auto-Failover | Simplicité | Cloud-ready |
Patroni | etcd | ✅ Oui | ⭐⭐⭐⭐ | ✅ Oui |
Stolon | etcd | ✅ Oui | ⭐⭐⭐ | ✅ Oui |
Repmgr | ❌ Non | ⚠️ Scripté | ⭐⭐ | ❌ Non |
Citus HA | Interne | ✅ 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.