Was ist PostgreSQL Streaming Replication (WAL) und wie richtet man sie ein?

• Die Streaming Replication von PostgreSQL ist eine effiziente Methode, um auf einem oder mehreren Standby-Servern eine nahezu in Echtzeit aktualisierte Replik der primären DB vorzuhalten
• Der primäre Server überträgt Write-Ahead Log (WAL)-Einträge fortlaufend an die Standby-Server, sobald sie erzeugt werden, und minimiert so die Verzögerung im Replikationsprozess
• Sie ist auf hohe Verfügbarkeit und bessere Skalierbarkeit ausgelegt; Leseabfragen können auf Standby-Server ausgelagert werden, um die Last auf dem primären Server zu reduzieren
• Unterstützt sowohl synchronen als auch asynchronen Modus, sodass sich das Gleichgewicht zwischen Datenkonsistenz und Performance flexibel anpassen lässt
• Umfasst den Prozess, bei dem sich ein Standby-Server mit dem Primärsystem verbindet, WAL-Streaming anfordert und die empfangenen Einträge auf seine eigene DB-Kopie anwendet
• Bietet im Vergleich zur dateibasierten Log-Übertragung schnelleres Failover und ein geringeres Risiko von Datenverlust und ist damit ideal für geografisch verteilte Umgebungen

Wie funktioniert Streaming Replication?

• WAL-Daten werden vom primären Server in Echtzeit und fortlaufend an den Standby-Server übertragen, sodass dessen DB nahezu identisch mit der primären bleibt
• Dadurch können Replikate für Master-Failover oder die Verarbeitung von Lesezugriffen genutzt werden, was dem System eine mehrfach höhere Skalierung ermöglicht

PostgreSQL-Konfigurationsdateien und Speicherorte

• Die PostgreSQL-Konfigurationsdateien spielen eine wichtige Rolle bei der Verwaltung der Einstellungen und des Verhaltens des Datenbankservers.
  • postgresql.conf: Die zentrale Konfigurationsdatei mit den meisten Servereinstellungen. Je nach Betriebssystem befindet sie sich an unterschiedlichen Orten, etwa /etc/postgresql/<version>/main/postgresql.conf (Debian/Ubuntu) oder /var/lib/pgsql/<version>/data/postgresql.conf (Red Hat/CentOS)
  • pg_hba.conf: Steuert die Client-Authentifizierung und definiert, wie Clients sich mit dem Server verbinden dürfen. Befindet sich in der Regel im selben Verzeichnis wie postgresql.conf
  • pg_ident.conf: Wird für die Zuordnung von Benutzernamen verwendet, kommt aber seltener zum Einsatz
  • recovery.conf: Wurde in PostgreSQL-Versionen vor 12 zur Konfiguration von Standby-Servern verwendet; in neueren Versionen wurden die Inhalte nach postgresql.conf und postgresql.auto.conf verlagert
• Der genaue Speicherort kann je nach Betriebssystem, Installationsmethode und PostgreSQL-Version variieren
  • Mit dem SQL-Befehl SHOW config_file; lässt sich innerhalb einer PostgreSQL-Instanz der Speicherort dieser Dateien ermitteln

WAL-Beispiel (Write Ahead Logs) und Struktur

• Mit dem Befehl pg_waldump lässt sich WAL anzeigen
• Jede Zeile stellt einen WAL-Eintrag dar, der Informationen über eine DB-Operation enthält
• Bestandteile jedes Eintrags:
  • rmgr: Ressourcenmanager (z. B. Heap, Btree, Transaction)
  • len: Eintragslänge
  • tx: Transaktions-ID
  • lsn: Log Sequence Number
  • prev: vorherige LSN
  • desc: Beschreibung der Operation
• Sichtbare Operationstypen:
  • INSERT-Operationen (Heap und Btree)
  • MULTI_INSERT-Operationen (Heap2)
  • COMMIT-Transaktionen
  • Dateioperationen (CREATE)
  • Full Page Writes (FPW)
• Die WAL-Ausgabe zeigt Transaktionsfluss, Datenänderungen und Systemaktivitäten im Detail und ist nützlich für die Analyse des DB-Verhaltens, Fehlerbehebung und Point-in-Time-Recovery

Arbeiten mit Docker

• Wichtige Einstellungen für Streaming Replication in postgresql.conf:
  • wal_level, max_wal_senders, max_replication_slots, hot_standby usw.
• Erforderlich für ein Docker-Compose-Beispiel:
  • init-master.sh: Richtet den PostgreSQL-Master für Replikation ein. Erstellt Replikationsbenutzer und Slots und aktualisiert WAL-bezogene Einstellungen
  • init-replica.sh: Bereitet das PostgreSQL-Replikat darauf vor, sich mit dem Master zu verbinden und die Replikation zu starten. Wartet, bis der Master bereit ist, führt dann ein Basis-Backup aus und konfiguriert das Replikat
  • start-replica.sh: Startet das PostgreSQL-Replikat im Docker-Container. Führt das Skript init-replica.sh aus und startet anschließend PostgreSQL
  • docker-compose.yml: Definiert Master- und Replikat-Dienste und legt die erforderlichen Umgebungsvariablen, Volumes, Befehle usw. fest
• Nach dem Setzen der Ausführungsrechte für die Skripte startet docker-compose up -d Master und Replikat
• Durch Verbindung mit dem Master kann der Replikationsstatus über pg_stat_replication geprüft werden
• Durch Verbindung mit dem Replikat kann mit pg_is_in_recovery() geprüft werden, ob es sich im Recovery-Modus befindet

Meinung von GN⁺

• Streaming Replication kann die Performance und Ausfallsicherheit einer Datenbankinfrastruktur erheblich verbessern. Ob zur Vorbereitung auf Failover-Szenarien oder zur Verteilung von Leselast auf Replikate – damit lässt sich die DB skalieren und stabile Performance sicherstellen
• Es ist wichtig, den gesamten Konfigurationsprozess und die Ausgaben zu zeigen. Das vermittelt eine ganzheitliche Sicht auf die vielen beweglichen Teile und hilft dabei, besser zu verstehen, was gerade passiert
• Zu verstehen, wie Streaming Replication funktioniert und wie sie korrekt konfiguriert wird, ist äußerst wichtig. Hoffentlich hat dieser Artikel den Prozess klarer gemacht und Einblicke in die Funktionsweise der Replikation gegeben
• Andere Produkte oder Projekte mit ähnlicher Funktionalität sind etwa die Replication von MySQL oder Oracle Data Guard. Auch diese Lösungen arbeiten, indem sie Änderungen vom Master an Replikate übertragen, auch wenn sich die Implementierungsdetails unterscheiden können
• Beim Einsatz von Streaming Replication sollten Netzwerkbandbreite und Latenz berücksichtigt werden. Die Datenübertragung zwischen Master und Replikat kann erhebliche Netzwerkressourcen verbrauchen. Auch die Skalierbarkeit der Replikate ist ein wichtiger Faktor
• Auch die Anforderungen an die Datenkonsistenz sollten bewertet werden. Synchrone Replikation kann die Schreib-Performance beeinträchtigen, bietet dafür aber stärkere Konsistenz. Asynchrone Replikation bietet bessere Performance, geht jedoch mit einer geringen Möglichkeit von Datenverlust einher

[GN⁺]

Hacker-News-Kommentar

• Es gibt die Meinung, dass dieser Artikel zwar hervorragend ist, aus der Perspektive eines Full-Stack-Entwicklers, der eine Datenbank betreiben möchte, jedoch konkrete Praxisbeispiele fehlen

  • Es wird gefragt, wie man prüfen kann, wie stark ein Replikat gegenüber dem Master verzögert ist
  • Als Methode zur Überwachung des Replikats wird vorgeschlagen, den Status mit einem einfachen cron-Job zu prüfen
  • Als komplexeres Problem wird gefragt, wie man auf ein Replikat umschaltet, wenn der Primärserver ausfällt
  • Es wird darüber nachgedacht, ob die Umschaltung automatisch oder manuell erfolgen sollte
  • Es wird bezweifelt, ob zwei Replikate nötig sind, um ein Split-Brain-Szenario zu vermeiden
  • Es wird gefragt, wie man nach der Umschaltung wieder in den ursprünglichen Zustand zurückkehrt

• Es wird behauptet, dass die einfachste Lösung für PostgreSQL-Replikation ein Kubernetes-Operator ist

  • Als Beispiel wird CloudnativePG genannt
  • Es wird erklärt, dass man nicht nur Replikation, sondern auch Failover, Wiederherstellung, Monitoring, Self-Healing und Backups benötigt
  • Es wird gefragt, ob es außer Kubernetes noch andere kostenlose/Open-Source-Implementierungen gibt

• Einer der Gründe für den Einsatz von Kubernetes und Helm sei, dass sich dieses Problem damit lösen lasse

  • Es wird erklärt, dass sich mit dem Bitnami-PostgreSQL-Paket nahezu alles ohne zusätzliche Konfiguration einrichten lässt
  • Es wird erklärt, dass Postgres-ha einen Proxy erstellt, der Ausfälle professionell behandelt und so unterbrechungsfreies Failover ermöglicht

• StackGres wird Kubernetes-Nutzern empfohlen

• Abschließend gibt es eine skeptische Meinung, dass dieser Artikel offenbar von KI geschrieben wurde