Cluster à failover automatique avec Patroni + etcd + HAProxy

Met en place et exploite un cluster PostgreSQL à failover automatique : sur chaque nœud, PostgreSQL est géré par Patroni, l'élection du leader se fait dans un etcd à 3 (ou 5) membres, et les applications se connectent aux ports d'écriture (5000) et de lecture (5001) de HAProxy, éventuellement via une VIP keepalived. En plus de l'installation, le guide contient des scénarios d'exploitation pour un cluster existant : contrôle de santé, switchover, réintégration de l'ancien leader, reinit, ajout/retrait d'un nœud, edit-config, pause, mise à niveau de Patroni, arrêt/démarrage complet, remplacement d'un membre etcd et perte du quorum etcd. Le guide pg-install ne s'utilise pas sur les nœuds Patroni (Patroni exécute lui-même initdb) ; pour une HA sans Patroni, avec failover manuel, utilisez le guide pg-streaming.

Topologie: 3 nœuds PostgreSQL + etcd (partagés ou séparés) + HAProxy (+ VIP)

Scénarios

• Installation : nouveau cluster Patroni — Construit de zéro un cluster etcd + Patroni + HAProxy (+ VIP). Les serveurs ne doivent pas contenir de cluster PostgreSQL : initdb est exécuté par Patroni (pg-install ne s'applique pas).
• Runbook d'exploitation : switchover, test de failover, mode maintenance, changement de paramètre — Déroule dans l'ordre les opérations de base sur un cluster nouvellement installé : état, switchover, test de failover (le leader est arrêté, courte interruption des écritures), mode maintenance, changement de paramètre. À exécuter dans une fenêtre de maintenance.
• Le cluster est-il sain ? (contrôle de santé) — Lecture seule : rôles, retard, timeline, API REST, santé d'etcd, slots, redémarrage en attente et mode maintenance.
• Switchover planifié (déplacer le leader sur un autre nœud) — Avant une maintenance, le rôle de leader passe de façon contrôlée à un replica ; quelques secondes d'interruption des écritures, pas de perte de données.
• Après un failover, l'ancien leader ne réintègre pas le cluster (pg_rewind / reinit) — Lorsque l'ancien leader tombé redémarre, il doit rejoindre le cluster comme replica ; si pg_rewind échoue, le répertoire de données est reconstruit à partir du leader.
• Reconstruire un replica de zéro (reinit) — Le replica est corrompu, très en retard ou a perdu des WAL : son répertoire de données est effacé et reconstruit à partir du leader (ou d'une sauvegarde). Le leader n'est pas affecté.
• Ajouter un nouveau nœud au cluster — Ajoutez le nouveau nœud à la fin de la liste du formulaire : les logiciels sont installés, pg_hba et HAProxy sont mis à jour sur les nœuds existants, et le nœud rejoint le cluster comme replica.
• Retirer un nœud du cluster — Un nœud replica est retiré définitivement : Patroni est arrêté, l'entrée DCS et le slot sont nettoyés, et le nœud est retiré de HAProxy.
• Modifier un paramètre PostgreSQL ou Patroni (edit-config) — Le paramètre est écrit dans le DCS et appliqué à tous les nœuds ; pour les paramètres qui exigent un redémarrage, restart --pending (les replicas d'abord).
• Suspendre le failover automatique pour une maintenance (pause / resume) — En pause, Patroni ne touche pas à PostgreSQL et n'effectue pas de failover ; pour une maintenance réseau/etcd ou une intervention manuelle. Faites resume une fois le travail terminé.
• Mettre à niveau le logiciel Patroni (rolling) — Le cluster est mis en pause, Patroni est mis à jour et redémarré nœud par nœud ; PostgreSQL reste démarré, aucun failover n'a lieu.
• Arrêter / démarrer tout le cluster (dans le bon ordre) — Arrêt complet planifié (maintenance du stockage, du datacenter) : les replicas d'abord, puis le leader, etcd en dernier ; démarrage dans l'ordre inverse.
• Remplacer ou ajouter un membre etcd (etcdctl member) — Le membre etcd défaillant est retiré et un nouveau serveur est ajouté (ou le nombre de membres est augmenté) ; la liste etcd de Patroni est mise à jour.
• Quorum etcd perdu : le leader est passé en lecture seule — Sans quorum etcd, Patroni met le leader en lecture seule et aucun failover n'a lieu non plus. etcd est rétabli ou reconstruit à partir d'un seul membre.

Avant de commencer

• Il n'y a aucun cluster PostgreSQL en fonctionnement ou créé auparavant sur les nœuds PostgreSQL et … est vide (Patroni crée lui-même le cluster). Le guide pg-install n'a pas été appliqué sur ces serveurs.
• Tous les serveurs sont dans la même version du système d'exploitation et à jour ; les horloges sont synchronisées par NTP (etcd et Patroni sont sensibles aux décalages d'horloge).
• … Go de RAM sur les nœuds PostgreSQL ; … est sur un disque/LV dédié, de même taille sur tous les nœuds.
• Les données etcd (/var/lib/etcd) sont sur un disque à faible latence (SSD). Un disque lent perturbe les élections de leader ; il est recommandé de ne pas les placer sur le même disque que les données PostgreSQL, très sollicitées en I/O.
• Attention : le nombre de nœuds etcd est … (pair). Un nombre pair n'augmente pas la tolérance aux pannes ; utilisez 3 ou 5.
• Les serveurs peuvent se joindre sur ces ports : PostgreSQL …, REST Patroni 8008, etcd 2379/2380, HAProxy 5000/5001/7000…, VRRP (protocole IP 112)…. Ces règles sont aussi ouvertes sur les équipements réseau intermédiaires.
• Les serveurs peuvent joindre en HTTPS le dépôt PGDG (download.postgresql.org…, apt.postgresql.org…) et github.com pour etcd, ou un miroir interne est configuré.
• La VIP … est libre (utilisée sur aucun serveur) et le réseau (virtualisation/cloud) autorise VRRP et le déplacement d'une même IP entre serveurs. Les environnements cloud ne l'autorisent généralement pas ; utilisez à la place le load balancer du cloud.
• Attention : il n'y a qu'un seul serveur HAProxy pour la VIP ; si ce serveur tombe, la VIP ne peut basculer nulle part.
• Accès root ou sudo sur tous les serveurs ; une fenêtre de maintenance et un plan de retour arrière sont prêts.
• … : le même système d'exploitation et la même version majeure de PostgreSQL que sur les autres nœuds peuvent être installés, autant de disque pour … que sur les autres nœuds, horloge synchronisée par NTP ; les accès à …, 8008 et etcd 2379 sur les autres nœuds sont ouverts.
• … (…) : disque à faible latence (SSD), horloge synchronisée par NTP, accès ouvert sur 2379/2380 depuis les autres membres etcd et sur 2379 depuis les nœuds PostgreSQL ; accès à github.com ou archive etcd dans /tmp.

Phases du guide

• Préparation (tous les serveurs) — Ajouter les noms des serveurs dans /etc/hosts · Activer la synchronisation de l'heure (chrony) · Paramètres du noyau et THP · Règles de firewall (nœuds PostgreSQL) · Règles de firewall (serveurs etcd) · Règles de firewall (serveurs HAProxy)
• Cluster etcd — Installer le logiciel etcd · Installer le logiciel etcd · Configuration etcd : … · Créer le service systemd d'etcd · Créer le service systemd d'etcd · Démarrer etcd (sur tous les nœuds etcd en même temps) …
• Logiciels PostgreSQL et Patroni — Ajouter le dépôt PGDG · Ajouter le dépôt PGDG · Installer PostgreSQL et Patroni · Désactiver le service PostgreSQL autonome et préparer les répertoires
• Configuration de Patroni — Écrire les mots de passe dans le fichier d'environnement · Rattacher le fichier d'environnement au service Patroni · patroni.yml : … · Valider la configuration
• Démarrer le cluster — Démarrer Patroni sur le premier nœud · Démarrer Patroni sur les autres nœuds : … · Vérifier l'état du cluster
• HAProxy — Installer HAProxy · Installer HAProxy · Écrire haproxy.cfg · Écrire haproxy.cfg · Valider et démarrer HAProxy · Valider et démarrer HAProxy
• VIP avec keepalived — Installer keepalived · Installer keepalived · Configuration keepalived : … · Démarrer keepalived · Démarrer keepalived
• Utilisateur applicatif et test de connexion — Utilisateur et base de données applicatifs · Définir le mot de passe de l'utilisateur applicatif · Vérifier les endpoints de health check de l'API REST · Tester la connexion via HAProxy · Chaîne de connexion de l'application
• Post-installation — Prendre une sauvegarde snapshot d'etcd · Prendre une sauvegarde snapshot d'etcd · Mettre en place les sauvegardes (obligatoire) · Raccorder la supervision
• État du cluster — Membres, rôles et retard
• Switchover planifié — Effectuer le switchover
• Test de failover (arrêter le leader) — Arrêter Patroni sur le nœud leader · Suivre le nouveau leader · Redémarrer l'ancien leader
• Mode maintenance (pause) — Passer le cluster en mode maintenance · Effectuer la maintenance · Sortir du mode maintenance
• Changement de paramètre — Modifier le paramètre pour tout le cluster · Appliquer les redémarrages en attente
• Contrôle de santé (lecture seule) — Membres, rôles, timeline et retard · Derniers changements de leader (history) · Endpoints de santé de l'API REST · Santé d'etcd · Retard de réplication, slots et redémarrage en attente (sur le leader) · Configuration et mode maintenance
• Switchover planifié — Contrôle avant switchover · Effectuer le switchover · Vérifier le nouveau leader et la réintégration de l'ancien
• Mode maintenance (pause / resume) — Contrôle avant la pause · Passer le cluster en mode maintenance (pause) · Effectuer la maintenance · Sortir du mode maintenance (resume)
• Mise à niveau de Patroni : préparation — Version actuelle et version cible de Patroni · Sauvegarder et valider la configuration · Passer le cluster en mode maintenance (pause)
• Mise à niveau de Patroni : fin — Sortir du mode maintenance (resume)
• Arrêter le cluster (replica → leader → etcd) — Enregistrer l'état et les rôles · Arrêter les applications · Arrêter Patroni sur les replicas · Arrêter Patroni sur le leader · Arrêter etcd
• Démarrer le cluster (etcd → dernier leader → replicas) — Démarrer etcd (sur tous les membres etcd en même temps) · Vérifier la santé d'etcd · Démarrer d'abord Patroni sur le dernier leader · Démarrer Patroni sur les replicas · Vérifier le cluster et redémarrer les applications
• Diagnostic : perte du quorum etcd — Confirmer les symptômes : pas de leader, PostgreSQL en lecture seule · Voir l'état des membres etcd
• Voie A : rétablir les membres etcd — Voie A : démarrer les services etcd · Vérifier que Patroni s'est rétabli
• Vérification et prévention — Vérifier etcd et Patroni, envisager le failsafe