Migration und Härtung eines PostgreSQL + Patroni-Produktionsclusters auf Ubuntu mit Replikationswiederherstellung und Backup-Einrichtung

Ausgangssituation
Derzeit wird PostgreSQL 14 in der Produktion für SaaS verwendet (Mehrmandantenfähigkeit, bis zu 1200 U/s in der Spitze, ~900 GB Daten). Cluster 3 Knoten (2x Primär/Standby + Zeuge) auf Ubuntu 20.04 in der Hetzner Cloud, verwaltet von Patroni+etcd. Nach einer Reihe von Vorfällen fielen uns auf: periodische Failovers mit Split-Brain, Replikate, die bis zu 20–40 Minuten zurückblieben, Barman-Backups waren manchmal fehlerhaft und Betriebssystem- und Postgres-Updates verzögerten sich. Der Plan besteht darin, mit minimaler Ausfallzeit auf Ubuntu 22.04 und PostgreSQL 16 zu migrieren und gleichzeitig Ordnung in die Beobachtbarkeit und den sicheren Betrieb zu bringen.

Technisches Umfeld
- 3 VM (Hetzner Cloud), NVMe, 1 Gbit/s Netzwerk
- Ubuntu 20.04 -> 22.04
- PostgreSQL 14 -> 16
- Patroni usw., HAProxy
- Barmann für PITR
- Prometheus + node_exporter ist bereits vorhanden, postgres_exporter ist an einigen Stellen konfiguriert
- Zugriff: SSH über Schlüssel, Leerlaufzeitbegrenzung – nicht mehr als 10 Minuten bei der endgültigen Umschaltung

Aufgabe und erwartetes Ergebnis
1) Analysieren Sie die aktuelle HA-Konfiguration (Patroni/etcd/HAProxy/Postgres) und identifizieren Sie die Ursachen für Split-Brain und Replikationsverzögerungen. Halten Sie die gefundenen Probleme und vorgeschlagenen Änderungen in einem kurzen Bericht fest.
2) Bereiten Sie einen Plan vor und führen Sie eine Migration auf PostgreSQL 16 und Ubuntu 22.04 durch, wobei der Patroni-Cluster und die transparente Umschaltung für Anwendungen über HAProxy erhalten bleiben.
3) Konfigurieren Sie Backups und Wiederherstellungsüberprüfung so, dass PITR und regelmäßige Validierung von Backups gewährleistet sind.
4) Stärkung der Sicherheit und Betriebszuverlässigkeit: Beschränkung des Netzwerkzugriffs, korrekte Kernel-/Limit-Parameter, Protokollrotation, grundlegende Härtungsmaßnahmen ohne Fanatismus.
5) Bringen Sie die Überwachung in einen Zustand, in dem Sie Replikationsverzögerung, Failover-Status, Festplattenfülle, Transaktionen mit langer Laufzeit und WAL-Wachstum messbar sehen können.

Einschränkungen
- Sie können das Anwendungs- und Datenbankschema nicht ändern (nur den Serverteil und die Postgres/Patroni/HAProxy-Parameter).
- Sie können keine verwaltete Datenbank verwenden, alles bleibt beim aktuellen Anbieter.
- Der Zugang zur Produktion ist eingeschränkt: Die Arbeit in der Hauptsendezeit besteht nur aus Lesen und Diagnostizieren, Änderungen und Schalten – gemäß einem vereinbarten Zeitfenster.
- Die Dokumentation muss für den Techniker, der die Anlage nach Abschluss der Arbeiten wartet, verständlich sein.

Akzeptanzkriterien (messbar)
– Der endgültige Wechsel zu einem neuen Primärserver dauert insgesamt 10 Minuten und beeinträchtigt den Dienst.
- Replikation im Normalmodus: Verzögerung im Standby-Modus < 5 Sekunden bei durchschnittlicher Auslastung (gemäß Metriken) und ohne WAL-Akkumulation.
- Split-Brain wurde eliminiert: Korrekte Quorum/Ttl/Loop_wait/retry_timeout-Einstellungen und Überprüfung des Netzwerk-/Knotenverlustszenarios am Stand oder in einem vereinbarten Fenster.
- Backups: tägliches Voll- oder Basisbackup und kontinuierliche Archivierung WAL, erfolgreiches PITR-Testverfahren mit Wiederherstellung auf einer separaten VM vor einem bestimmten Zeitpunkt.
- Überwachung: Postgres-Metriken sind in Prometheus verfügbar (einschließlich Replikationsverzögerung, WAL, lang laufende Abfragen), es gibt mindestens 5 Warnungen (Festplatte, Verzögerung, Nichtverfügbarkeit des Knotens, zunehmende Fehler, Stoppen von Sicherungen).
- Übertragung von Artefakten: aktuelle Patroni/HAProxy/Postgres-Konfigurationen, Anweisungen zur Aktualisierung und Notfallwiederherstellung, Liste der vorgenommenen Änderungen.

Ausführungsschritte
- Prüfung und Aufzeichnung des aktuellen Zustands, Erfassung von Metriken und Protokollen, Diagnose von Vorfällen.
- Entwurf des Zielschemas und Migrationsplans mit Rollback.
- Bereitstellung neuer VMs, Übertragung von Konfigurationen, Konfiguration von Patroni/etcd/HAProxy.
- Datenmigration (pg_basebackup/pg_upgrade oder vereinbarte Methode), Durchführung von Prüfungen.
- Barmann-Setup und PITR-Test.
- Einrichten von Überwachungen und Warnungen, abschließende Überprüfung und Übertragung der Dokumentation.

Professionelle Werkzeuge, die Sie benötigen
- patronictl, etcdctl, psql, pgBackRest oder barman, pgbench (oder ein Analogon zum Ausführen), Prometheus exporters, tcpdump/ss, journald/rsyslog, Ansible (vorzugsweise) für die Reproduzierbarkeit.

Wichtig
Gefragt ist die praktische Arbeit an der Infrastruktur mit Analyse und sorgfältiger Migration und nicht eine allgemeine Beratung.