🐘 PostgreSQL 17 HA : Guide Complet pour Créer un Cluster Haute Disponibilité avec Patroni, etcd et HAProxy

🔴 Niveau : Avancé | ⏱️ Lecture : 45 min | 🛠️ Mise en œuvre : 2-4 heures

📚 Prérequis

3 serveurs Linux (Debian 12/13 ou Ubuntu 22.04/24.04 LTS)
Accès root ou sudo sur tous les serveurs
Réseau privé entre les serveurs
Connaissances de base en administration Linux et PostgreSQL

La haute disponibilité de PostgreSQL est essentielle pour toute application critique en production. Dans ce tutoriel complet, nous allons déployer un cluster PostgreSQL 17 avec failover automatique en utilisant Patroni pour l’orchestration, etcd pour le consensus distribué, et HAProxy pour le load balancing intelligent.

Ce guide vous permettra de configurer de zéro une infrastructure PostgreSQL HA robuste, prête pour la production.

🏗️ Architecture du Cluster

Notre cluster sera composé de 3 nœuds avec tous les composants colocalisés :

📊 Rôle de chaque composant

etcd : Base de données distribuée clé-valeur qui stocke l’état du cluster et gère l’élection du leader via un algorithme de consensus (Raft)
Patroni : Template de haute disponibilité pour PostgreSQL qui gère le failover automatique, la réplication streaming et l’initialisation du cluster
HAProxy : Load balancer qui route les connexions vers le bon nœud (écriture vers Primary, lecture vers Replicas)
PostgreSQL 17 : Le serveur de base de données en réplication streaming

🔌 Ports utilisés

Port	Service	Description
5432	PostgreSQL	Base de données
8008	Patroni REST API	Health checks et gestion
2379	etcd client	Communication client
2380	etcd peer	Communication inter-nœuds
5000	HAProxy RW	Read-Write (Primary)
5001	HAProxy RO	Read-Only (Replicas)
7000	HAProxy Stats	Interface web

⚙️ Étape 1 : Préparation des Serveurs

Commençons par préparer nos 3 serveurs. Dans cet exemple, nous utilisons :

pg-node-1 : 192.168.1.10
pg-node-2 : 192.168.1.11
pg-node-3 : 192.168.1.12

1.1 Configuration du fichier /etc/hosts

Sur chaque serveur, ajoutez les entrées suivantes dans /etc/hosts :

1.2 Installation des paquets prérequis

Sur chaque serveur, installez les dépendances communes :

🔐 Étape 2 : Installation et Configuration de etcd

etcd est le cœur de notre système de haute disponibilité. Il stocke l’état du cluster et gère l’élection du leader PostgreSQL.

2.1 Téléchargement et installation des binaires

Sur chaque serveur, téléchargez etcd depuis GitHub :

2.2 Création de l’utilisateur etcd

2.3 Configuration de etcd

Créez le fichier de configuration /etc/etcd/etcd.conf. Attention : le contenu varie selon le serveur !

Sur pg-node-1 (192.168.1.10) :

Sur pg-node-2 (192.168.1.11) :

Sur pg-node-3 (192.168.1.12) :

2.4 Fichier d'état initial

Sur chaque serveur, créez le fichier d'état initial :

2.5 Service systemd pour etcd

Sur chaque serveur, créez le fichier /etc/systemd/system/etcd.service :

2.6 Démarrage du cluster etcd

Important : Démarrez etcd sur les 3 nœuds simultanément (ou dans un délai de quelques secondes) :

2.7 Vérification du cluster etcd

Vous devriez voir les 3 membres avec un statut "healthy".

🐘 Étape 3 : Installation de PostgreSQL 17

Sur chaque serveur, installez PostgreSQL depuis le dépôt officiel PGDG :

3.1 Ajout du dépôt PostgreSQL

3.2 Installation de PostgreSQL 17

3.3 Désactivation et suppression du cluster par défaut

Patroni va gérer l'initialisation de PostgreSQL. Le cluster par défaut doit être supprimé :

🎭 Étape 4 : Installation et Configuration de Patroni

Patroni est l'orchestrateur qui va gérer le failover automatique de PostgreSQL.

4.1 Installation de Patroni

Sur chaque serveur :

4.2 Création du répertoire de configuration

4.3 Configuration de Patroni

Créez le fichier /etc/patroni/patroni.yml. Adaptez les mots de passe et l'adresse IP selon le serveur !

Sur pg-node-1 (192.168.1.10) :

Sur pg-node-2 et pg-node-3, utilisez la même configuration en remplaçant :

name: par pg-node-2 ou pg-node-3
Toutes les occurrences de 192.168.1.10 par l'IP du serveur correspondant

4.4 Service systemd pour Patroni

Sur chaque serveur :

4.5 Démarrage de Patroni

Important : Démarrez Patroni séquentiellement, un nœud à la fois, en commençant par pg-node-1 :

4.6 Vérification du cluster Patroni

⚖️ Étape 5 : Installation et Configuration de HAProxy

HAProxy va permettre de router automatiquement les connexions vers le bon serveur PostgreSQL.

5.1 Installation de HAProxy

Sur chaque serveur :

5.2 Configuration de HAProxy

Remplacez le contenu de /etc/haproxy/haproxy.cfg :

5.3 Validation et démarrage de HAProxy

✅ Étape 6 : Tests et Validation

6.1 Test de connexion via HAProxy

6.2 Test de failover

6.3 Interface HAProxy Stats

Accédez à l'interface web de HAProxy : http://192.168.1.10:7000 (login: admin / password: admin)

🔧 Commandes Utiles

🚀 Conclusion : Automatisez avec Ansible !

Vous venez de déployer manuellement un cluster PostgreSQL HA complet. Cette configuration vous offre :

✅ Failover automatique en moins de 30 secondes
✅ Réplication streaming avec lag minimal
✅ Routage intelligent des connexions
✅ Consensus distribué pour une élection de leader fiable

Cependant, ce processus manuel est long, répétitif et source d'erreurs. Pour des déploiements en production, nous recommandons fortement d'automatiser avec Ansible.

Notre rôle postgres_ha déploie cette architecture complète en quelques minutes :

🔄 Idempotent : Exécutez-le autant de fois que nécessaire
⚙️ Configurable : Modes colocalisé ou dédié pour etcd/HAProxy
✅ Testé : Validé avec Molecule sur Debian 12/13 et Ubuntu 22.04/24.04
📚 Documenté : Guides Day-1 et Day-2 inclus

Découvrir le rôle postgres_ha

📖 Glossaire

etcd : Base de données distribuée clé-valeur utilisant l'algorithme de consensus Raft
Patroni : Template de haute disponibilité pour PostgreSQL développé par Zalando
HAProxy : Load balancer et proxy TCP/HTTP haute performance
Failover : Basculement automatique vers un serveur de secours en cas de panne
Switchover : Basculement manuel et contrôlé vers un autre serveur
Streaming Replication : Réplication en temps réel des transactions PostgreSQL
Quorum : Nombre minimum de nœuds nécessaires pour prendre une décision (ici 2 sur 3)

Ce tutoriel vous a été utile ? Partagez-le avec vos collègues DevOps !