PostgreSQL Streaming Replication (Primary + Standby)

Fügt einem installierten Primary per pg_basebackup einen oder mehrere Hot Standbys hinzu (Replikationsbenutzer, pg_hba, Replication Slot, asynchroner oder synchroner ANY/FIRST-Modus, Lag-Überwachung) und erzeugt die Betriebs-Runbooks für diesen Cluster ohne Patroni: geplanter Switchover, manueller Failover (pg_promote), Wiedereingliederung des alten Primary mit pg_rewind, Neuaufbau eines Standby, kaskadierende und verzögerte Standbys, Slot-Bereinigung, Änderung der synchronen Einstellungen. Der Failover erfolgt nicht automatisch, sondern durch den DBA; für automatischen Failover pg-patroni, für Datenfluss auf Tabellenebene oder zwischen Versionen pg-logical-repl.

Topologie: 1 Primary + 1..N Standbys

Szenarien

• Einrichtung: Standbys zum Primary hinzufügen — Einem installierten Primary werden per pg_basebackup ein oder mehrere Hot Standbys hinzugefügt (Slot, synchron/asynchron, Überwachung). Der Primary bleibt in Betrieb; die Erstkopie belastet Platten und Netz des Primary.
• Geplanter Switchover (Rollentausch, kein Datenverlust) — Geplante Wartung: Der Primary wird sauber heruntergefahren, der erste Standby wird promotet, der alte Primary kommt als Standby zurück. Kein Datenverlust; die Schreibunterbrechung dauert meist unter einer Minute.
• Manueller Failover (Primary ausgefallen, Standby promoten) — Der Primary ist ausgefallen oder nicht erreichbar: Der alte Primary wird isoliert (Fencing), der aktuellste Standby wird von Hand promotet. Im asynchronen Modus können die letzten Transaktionen verloren gehen.
• Alten Primary mit pg_rewind als Standby wieder einbinden — Nach einem Failover wird der alte Primary mit pg_rewind auf den neuen Primary abgeglichen und als Standby wieder eingebunden; deutlich schneller als eine Vollkopie.
• Neuen Standby hinzufügen, der von einem Standby versorgt wird (Cascading) — Der neue Standby bezieht WAL vom ersten Standby statt vom Primary: In einem entfernten Rechenzentrum oder bei vielen Standbys sinkt die Netz- und WAL-Sender-Last des Primary. Der Primary ist nicht betroffen.
• Verzögerten Standby (Delayed Standby) einrichten — Ein Standby, der WAL erst Stunden später anwendet (recovery_min_apply_delay): um versehentlich gelöschte Daten zu retten, ohne aus dem Backup wiederherzustellen. Er ist kein Failover-Kandidat.
• Standby von Grund auf neu aufbauen — Der Standby ist zurückgefallen, sein WAL wurde gelöscht oder er ist beschädigt: Das Datenverzeichnis wird beiseitegelegt und erneut vom Primary kopiert. Der Primary ist nicht betroffen.
• pg_wal wächst, Platte läuft voll (ungenutzte Slots bereinigen) — Die Ursache des WAL-Rückstaus wird ermittelt (inaktiver Slot, Archivierungsfehler, wal_keep_size); der ungenutzte Replication Slot wird gelöscht und WAL-Speicher zurückgewonnen. Der Primary bleibt in Betrieb.
• Synchronen Standby hinzufügen / entfernen (synchronous_standby_names) — Schreibt die synchrone Liste gemäß dem Modus im Formular (ANY/FIRST, k) neu oder stellt auf asynchron zurück; wird per Reload übernommen, kein Restart nötig. Eine falsche Einstellung kann Commits hängen lassen; deshalb wird vorher geprüft.

Vor dem Start

• Der Primary … ist mit dem Guide pg-install installiert und läuft (PostgreSQL …, PGDATA …, Port …).
• Auf den Standby-Servern wurde vom Guide pg-install nur die Phase Betriebssystemvorbereitung (Hostname, chrony, sysctl, THP) durchgeführt. Der Cluster wurde nicht angelegt; die Software wird in diesem Guide installiert.
• Auf allen Servern dieselbe Betriebssystemfamilie, dieselbe Architektur (x86_64/aarch64) und dieselbe PostgreSQL-Hauptversion (…). Ein Standby ist eine exakte physische Kopie des Primary.
• Auf dem Standby ist für … mindestens 20 % mehr freier Platz vorhanden, als die Daten auf dem Primary belegen.
• Die Server erreichen sich gegenseitig über Port …; Hostnamen werden aufgelöst und die Uhren sind per NTP synchron.
• Port … ist in der Firewall zwischen den Servern offen (hat pg-install nur das Anwendungsnetz freigegeben, füge auch die Replikations-IPs hinzu).
• Unter Debian/Ubuntu liegen die Konfigurationsdateien außerhalb des Datenverzeichnisses (/etc/postgresql), daher kopiert pg_basebackup sie nicht; du hast vom Standby zum Primary scp-Zugriff als root (oder als Benutzer mit sudo) oder überträgst die Dateien von Hand.
• Das Datenverzeichnis des alten Primary ist intakt und der Server lässt sich starten (nach einem Plattenausfall ist statt pg_rewind ein Neuaufbau mit pg_basebackup nötig).
• …Für die Erstkopie (pg_basebackup), die den Primary belastet, wurde ein passender Zeitpunkt gewählt.…Das Wartungsfenster ist offen; die Anwendungsteams wissen von der kurzen Schreibunterbrechung.…Es ist bestätigt, dass der Primary wirklich nicht erreichbar ist; es ist sichergestellt, dass er nicht zurückkommt und als zweiter Primary Schreibvorgänge annimmt (Fencing).…Der neue Primary ist gesund und nimmt Schreibvorgänge an.…Der neue Server (…) ist bereit: Die Betriebssystemvorbereitung ist erledigt, … ist leer und hat genug Platz; die Erstkopie belastet die Quelle (…).…Während … neu aufgebaut wird, kann die Leselast auf die anderen Server verlagert werden; die Kopie belastet den Primary.…Die Plattenbelegung wird überwacht; vor dem Löschen des Slots wurde mit dem Verantwortlichen des Standby gesprochen, der ihn nutzt.…Die synchrone Änderung erfolgt im Wartungsfenster; die Anwendungsteams sind informiert, da sich die Commit-Latenz ändert.…

Phasen der Anleitung

• Vorbereitung (alle Server) — Servernamen in /etc/hosts eintragen · PGDG-Repository hinzufügen · PGDG-Repository hinzufügen · PostgreSQL-Serversoftware installieren · Datenverzeichnis vorbereiten · Cluster-Konfiguration anlegen und Datenverzeichnis leeren
• Replikationsvorbereitung auf dem Primary — Voraussetzung für pg_rewind prüfen · Replikations-Einstellungsdatei schreiben · Einstellungen laden · Replikationsbenutzer anlegen · Passwort für den Replikationsbenutzer setzen · Replikationsregeln in pg_hba.conf eintragen …
• Standby-Einrichtung (pg_basebackup) — Replikationsverbindung zum Primary testen · Kopie des Primary ziehen: … · Konfigurationsdateien vom Primary kopieren · Standby starten
• Prüfung — Replikationsstatus auf dem Primary prüfen · WAL-Receiver auf dem Standby prüfen · Testdaten auf dem Primary schreiben · Testdaten auf dem Standby lesen · Testtabelle löschen
• Synchrone Replikation aktivieren — Datei für synchrone Einstellungen schreiben · Einstellung auf allen Servern laden · Synchronen Status prüfen
• Überwachung und Nacharbeiten — Abfrage zur Lag-Überwachung (Primary) · Abfrage zur Lag-Überwachung (Standby) · Slot-Belegung überwachen · Verbindungsstring der Anwendung · Backup auf den Standby abstimmen
• Prüfung vor dem Switchover — Status der Standbys prüfen · Bereitschaft des neuen Primary prüfen · .pgpass und pg_hba auf dem alten Primary prüfen
• Switchover — Alten Primary sauber herunterfahren · Prüfen, dass der neue Primary das letzte WAL empfangen hat · … promoten · Slots auf dem neuen Primary anlegen · Alten Primary als Standby konfigurieren · Alten Primary als Standby starten …
• Manueller Failover — Alten Primary stoppen und deaktivieren (Fencing) · Aktuellsten Standby ermitteln · … promoten · Synchrones Warten vorübergehend aufheben · Slots auf dem neuen Primary anlegen · Übrige Standbys auf den neuen Primary umstellen: … …
• Alten Primary mit pg_rewind wieder einbinden — Slot und Verbindungsregel auf dem neuen Primary prüfen · Prüfen, dass der alte Primary gestoppt ist · pg_rewind-Testlauf · pg_rewind ausführen · Standby-Einstellungen vervollständigen · Alten Primary als Standby starten …
• pg_wal-Aufblähung und Slot-Bereinigung — Warum wächst pg_wal? · Besitzer des Slots ermitteln · Ungenutzten Slot löschen: … · Slot löschen: Formular ausfüllen · Prüfen, dass WAL-Speicher zurückgewonnen wurde · Wiederholung verhindern: Obergrenze und Überwachung
• Änderung synchroner Standbys — Aktueller synchroner Status · Sicherheitsprüfung: Sind genug Standbys verbunden? · Datei für synchrone Einstellungen schreiben · Synchrone Einstellung entfernen (zurück zu asynchron) · Einstellung auf allen Servern laden · Neuen Status prüfen