Cluster mit automatischem Failover mit Patroni + etcd + HAProxy

Richtet einen PostgreSQL-Cluster mit automatischem Failover ein und betreibt ihn: Auf jedem Node verwaltet Patroni PostgreSQL, die Leader-Wahl läuft über ein etcd mit 3 (oder 5) Mitgliedern, Anwendungen verbinden sich mit dem Schreib-Port (5000) und Lese-Port (5001) von HAProxy, optional über eine keepalived-VIP. Neben der Installation gibt es Betriebsszenarien für einen bestehenden Cluster: Health Check, Switchover, Wiederaufnahme des alten Leaders, Reinit, Node hinzufügen/entfernen, edit-config, Pause, Patroni-Upgrade, vollständiges Herunterfahren/Hochfahren, Austausch von etcd-Mitgliedern und Verlust des etcd-Quorums. Der Guide pg-install wird auf Patroni-Nodes nicht verwendet (initdb führt Patroni selbst aus); für HA ohne Patroni mit manuellem Failover nutze den Guide pg-streaming.

Topologie: 3 PostgreSQL- + etcd-Nodes (gemeinsam oder getrennt) + HAProxy (+ VIP)

Szenarien

• Installation: neuer Patroni-Cluster — Baut einen etcd- + Patroni- + HAProxy- (+ VIP-)Cluster von Grund auf. Auf den Servern darf kein PostgreSQL-Cluster existieren: initdb führt Patroni aus (pg-install wird nicht angewendet).
• Betriebs-Runbook: Switchover, Failover-Test, Wartungsmodus, Parameteränderung — Spielt die grundlegenden Vorgänge auf einem neu aufgebauten Cluster der Reihe nach durch: Status, Switchover, Failover-Test (der Leader wird gestoppt, kurze Schreibunterbrechung), Wartungsmodus, Parameteränderung. Führe das in einem Wartungsfenster aus.
• Ist der Cluster gesund? (Health Check) — Nur lesend: Rollen, Lag, Timeline, REST API, etcd-Zustand, Slots, ausstehender Restart und Wartungsmodus.
• Geplanter Switchover (Leader auf einen anderen Node verlegen) — Vor einer Wartung geht die Leader-Rolle kontrolliert auf eine Replica über; einige Sekunden Schreibunterbrechung, kein Datenverlust.
• Failover ist passiert, der alte Leader tritt nicht wieder bei (pg_rewind / reinit) — Der ausgefallene alte Leader sollte nach dem Start als Replica beitreten; schlägt pg_rewind fehl, wird das Datenverzeichnis vom Leader neu aufgebaut.
• Eine Replica von Grund auf neu aufbauen (reinit) — Die Replica ist beschädigt, weit zurück oder hat WAL verloren: Ihr Datenverzeichnis wird gelöscht und vom Leader (oder aus einem Backup) neu aufgebaut. Der Leader ist nicht betroffen.
• Neuen Node zum Cluster hinzufügen — Füge den neuen Node am Ende der Liste im Formular hinzu: Die Software wird installiert, pg_hba und HAProxy werden auf den bestehenden Nodes aktualisiert, und der Node tritt als Replica bei.
• Node aus dem Cluster entfernen — Ein Node, der Replica ist, wird dauerhaft entfernt: Patroni wird gestoppt, DCS-Eintrag und Slot werden bereinigt, und er wird aus HAProxy entfernt.
• PostgreSQL- oder Patroni-Einstellung ändern (edit-config) — Die Einstellung wird in den DCS geschrieben und auf alle Nodes angewendet; bei Einstellungen, die einen Restart erfordern, restart --pending (zuerst die Replicas).
• Automatisches Failover für die Wartung anhalten (pause / resume) — Im Pause-Modus fasst Patroni PostgreSQL nicht an und führt kein Failover aus; für Netzwerk-/etcd-Wartung oder manuelle Eingriffe. Danach resume.
• Patroni-Software aktualisieren (rolling) — Der Cluster wird pausiert, Patroni wird Node für Node aktualisiert und neu gestartet; PostgreSQL läuft weiter, es gibt kein Failover.
• Gesamten Cluster stoppen / starten (richtige Reihenfolge) — Geplantes vollständiges Herunterfahren (Storage-, Rechenzentrumswartung): zuerst die Replicas, dann der Leader, zuletzt etcd; Hochfahren in umgekehrter Reihenfolge.
• etcd-Mitglied austauschen oder hinzufügen (etcdctl member) — Ein ausgefallenes etcd-Mitglied wird entfernt und ein neuer Server hinzugefügt (oder die Anzahl der Mitglieder erhöht); die etcd-Liste von Patroni wird aktualisiert.
• etcd-Quorum verloren: Der Leader ist schreibgeschützt — Ohne etcd-Quorum setzt Patroni den Leader auf schreibgeschützt, und es gibt auch kein Failover. etcd wird wiederhergestellt oder aus einem einzelnen Mitglied neu aufgebaut.

Vor dem Start

• Auf den PostgreSQL-Nodes gibt es keinen laufenden oder zuvor angelegten PostgreSQL-Cluster, und … ist leer (Patroni legt den Cluster selbst an). Der Guide pg-install wurde auf diesen Servern nicht angewendet.
• Alle Server laufen mit demselben Betriebssystem-Release und sind aktuell; die Uhren sind per NTP synchronisiert (etcd und Patroni reagieren empfindlich auf Zeitabweichungen).
• … GB RAM auf den PostgreSQL-Nodes; … liegt auf einer eigenen Disk/LV und ist auf allen Nodes gleich groß.
• Die etcd-Daten (/var/lib/etcd) liegen auf einer Disk mit niedriger Latenz (SSD). Eine langsame Disk stört die Leader-Wahl; die Disk sollte nicht mit den I/O-intensiven PostgreSQL-Daten geteilt werden.
• Achtung: Die Anzahl der etcd-Nodes ist … (gerade). Eine gerade Anzahl erhöht die Ausfalltoleranz nicht; verwende 3 oder 5.
• Die Server erreichen sich gegenseitig über diese Ports: PostgreSQL …, Patroni REST 8008, etcd 2379/2380, HAProxy 5000/5001/7000…, VRRP (IP-Protokoll 112)…. Diese Regeln sind auch auf den Netzwerkgeräten dazwischen freigegeben.
• Die Server erreichen per HTTPS das PGDG-Repository (download.postgresql.org…, apt.postgresql.org…) und für etcd github.com, oder ein interner Mirror ist eingerichtet.
• Die VIP … ist frei (auf keinem Server in Verwendung), und das Netzwerk (Virtualisierung/Cloud) erlaubt VRRP und das Verschieben derselben IP zwischen Servern. In Cloud-Umgebungen ist das meist nicht erlaubt; verwende dort den Load Balancer der Cloud.
• Achtung: Für die VIP gibt es nur einen HAProxy-Server; fällt dieser aus, kann die VIP nirgendwohin wechseln.
• root- oder sudo-Rechte auf allen Servern; Wartungsfenster und Rückfallplan liegen bereit.
• …: Dasselbe Betriebssystem und dieselbe PostgreSQL-Hauptversion wie auf den anderen Nodes sind installierbar, so viel Disk für … wie auf den anderen Nodes, Uhr per NTP synchronisiert; Zugriff auf …, 8008 und etcd 2379 der anderen Nodes ist freigegeben.
• … (…): Disk mit niedriger Latenz (SSD), Uhr per NTP synchronisiert, Zugriff auf 2379/2380 von den anderen etcd-Mitgliedern und auf 2379 von den PostgreSQL-Nodes ist freigegeben; Zugriff auf github.com oder das etcd-Archiv liegt in /tmp.

Phasen der Anleitung

• Vorbereitung (alle Server) — Servernamen in /etc/hosts eintragen · Zeitsynchronisation (chrony) aktivieren · Kernel-Einstellungen und THP · Firewall-Regeln (PostgreSQL-Nodes) · Firewall-Regeln (etcd-Server) · Firewall-Regeln (HAProxy-Server)
• etcd-Cluster — etcd-Software installieren · etcd-Software installieren · etcd-Konfiguration: … · etcd-systemd-Dienst anlegen · etcd-systemd-Dienst anlegen · etcd starten (auf allen etcd-Nodes gleichzeitig) …
• PostgreSQL- und Patroni-Software — PGDG-Repository hinzufügen · PGDG-Repository hinzufügen · PostgreSQL und Patroni installieren · Eigenständigen PostgreSQL-Dienst deaktivieren und Verzeichnisse vorbereiten
• Patroni-Konfiguration — Passwörter in die Umgebungsdatei schreiben · Umgebungsdatei an den Patroni-Dienst anbinden · patroni.yml: … · Konfiguration validieren
• Cluster starten — Patroni auf dem ersten Node starten · Patroni auf den anderen Nodes starten: … · Cluster-Status prüfen
• HAProxy — HAProxy installieren · HAProxy installieren · haproxy.cfg schreiben · haproxy.cfg schreiben · HAProxy prüfen und starten · HAProxy prüfen und starten
• VIP mit keepalived — keepalived installieren · keepalived installieren · keepalived-Konfiguration: … · keepalived starten · keepalived starten
• Anwendungsbenutzer und Verbindungstest — Anwendungsbenutzer und Datenbank · Passwort des Anwendungsbenutzers setzen · Health-Check-Endpunkte der REST API prüfen · Verbindung über HAProxy testen · Verbindungsstring der Anwendung
• Nach der Installation — etcd-Snapshot-Backup erstellen · etcd-Snapshot-Backup erstellen · Backup einrichten (Pflicht) · Monitoring anbinden
• Cluster-Status — Mitglieder, Rollen und Lag
• Geplanter Switchover — Switchover durchführen
• Failover-Test (Leader stoppen) — Patroni auf dem Leader-Node stoppen · Neuen Leader beobachten · Alten Leader wieder starten
• Wartungsmodus (pause) — Cluster in den Wartungsmodus versetzen · Wartung durchführen · Wartungsmodus beenden
• Parameteränderung — Parameter für den ganzen Cluster ändern · Ausstehende Restarts anwenden
• Health Check (nur lesend) — Mitglieder, Rollen, Timeline und Lag · Letzte Leader-Wechsel (history) · Health-Endpunkte der REST API · etcd-Zustand · Replikations-Lag, Slots und ausstehender Restart (auf dem Leader) · Konfiguration und Wartungsmodus
• Geplanter Switchover — Prüfung vor dem Switchover · Switchover durchführen · Neuen Leader und Wiederaufnahme des alten Leaders prüfen
• Wartungsmodus (pause / resume) — Prüfung vor pause · Cluster in den Wartungsmodus versetzen (pause) · Wartung durchführen · Wartungsmodus beenden (resume)
• Patroni-Upgrade: Vorbereitung — Aktuelle und Ziel-Version von Patroni · Konfiguration sichern und validieren · Cluster in den Wartungsmodus versetzen (pause)
• Patroni-Upgrade: Abschluss — Wartungsmodus beenden (resume)
• Cluster stoppen (Replica → Leader → etcd) — Zustand und Rollen festhalten · Anwendungen stoppen · Patroni auf den Replicas stoppen · Patroni auf dem Leader stoppen · etcd stoppen
• Cluster starten (etcd → letzter Leader → Replicas) — etcd starten (auf allen etcd-Mitgliedern gleichzeitig) · etcd-Zustand prüfen · Patroni zuerst auf dem letzten Leader starten · Patroni auf den Replicas starten · Cluster prüfen und Anwendungen starten
• Diagnose: Verlust des etcd-Quorums — Symptome bestätigen: kein Leader, PostgreSQL schreibgeschützt · Zustand der etcd-Mitglieder anzeigen
• Weg A: etcd-Mitglieder zurückholen — Weg A: etcd-Dienste starten · Prüfen, dass Patroni sich erholt hat
• Prüfung und Vorbeugung — etcd und Patroni prüfen, failsafe abwägen