pgactive – Active-Active-Replikationserweiterung für Postgres

• Eine von AWS entwickelte und veröffentlichte Active-Active-Replikations-Erweiterung für PostgreSQL
• Wenn Daten auf mehreren PostgreSQL-Instanzen geschrieben und geändert werden müssen, kann statt des bisherigen Active-Standby-Modells, bei dem nur eine bestimmte Instanz Änderungen annimmt, eine Struktur aufgebaut werden, die gleichzeitige Änderungen und Replikation auf mehreren Instanzen ermöglicht
• Geeignet für Szenarien wie hochverfügbare Datenbankkonfigurationen über mehrere Regionen, Minimierung von Schreibverzögerungen, Blue/Green-Updates von Anwendungen und bidirektionale Datenmigration
• Nutzt logische Replikation und unterstützt dadurch Konflikterkennung, Auflösung von Schreibkonflikten sowie Formatumwandlungen für Zieldatenbanken

Konzept der Active-Active-Replikation

• Replikation ist eine Technik zur Synchronisierung von Änderungen zwischen Datenbanken
• Die bestehende Active-Standby-Architektur von PostgreSQL lässt nur auf einer Instanz Änderungen zu, während die übrigen schreibgeschützt sind; dadurch gibt es eine einzelne Datenquelle
• pgactive bietet eine Active-Active-Replikationstopologie und erlaubt damit gleichzeitige Schreibvorgänge auf mehreren Instanzen
• Dieser Ansatz eignet sich für Umgebungen mit mehreren Schreibpunkten, etwa Multi-Region-Deployments oder bidirektionale Migrationen
• Im Active-Active-Modell müssen Konflikte, Latenzen und bestimmte funktionale Einschränkungen gesondert verwaltet werden

Schlüsseltechnologie: logische Replikation

• Logische Replikation (Logical Replication) überträgt Daten in einem Format, das von externen Systemen interpretiert werden kann
• Durch logische Replikation lassen sich in der Zieldatenbank verschiedene Zusatzfunktionen umsetzen, darunter Konflikterkennung, Auflösung von Schreibkonflikten und Abfragetransformationen
• PostgreSQL führte 2017 mit Version 10 eine grundlegende logische Replikation ein, für Active-Active-Replikation sind jedoch zusätzliche Funktionen erforderlich
• Aufgrund der Entwurfseigenschaften von PostgreSQL können diese Funktionen in Form einer Erweiterung (Extension) entwickelt und eingesetzt werden
• Auch die PostgreSQL-Entwickler-Community ergänzt nach und nach entsprechende Funktionen im Kernprojekt

[GN⁺]

Hacker-News-Kommentare

• Ich habe versucht, die Entwicklungsgeschichte von BDR, pglogical, pgactive und Postgres Distributed (PGD) zusammenzufassen, basierend auf dem, was ich von Teamkollegen bei 2nd Quadrant und EDB gehört habe.
  Als Erstes erschien BDR1, das bis heute Open Source ist (Link); darauf basiert pgactive.
  BDR2 war eine Closed-Source-Neuschreibung von BDR1 und wurde schließlich verworfen.
  Danach erschienen pglogical v1 und v2 (beide Open Source, Link); v1 wurde dabei stark überarbeitet und in Postgres 10 aufgenommen.
  Auf Grundlage der Erfahrungen mit der logischen Replikation in Postgres 10 begann 2nd Quadrant mit der Entwicklung von pglogical v2, woraus auch pgEdge hervorging.
  Später entwickelte 2nd Quadrant die Closed-Source-Versionen pglogical v3 und BDR v3, die dann zu BDR v4 zusammengeführt wurden.
  Danach wurde das Produkt BDR in Postgres Distributed (PGD, Link) umbenannt.
  Nach der Übernahme von 2ndQuadrant durch EDB veröffentlichte EDB PGD v6.
  • Auch PostgresPro hat ein separates Multi-Master-Replikationssystem Dokumentationslink
  • Es wird gefragt, ob PGDv6 weiterhin Closed Source ist.
• Dieses System verwendet die logische Replikation von Postgres, um Änderungen von einer Instanz an andere Instanzen zu übertragen.
  Wenn Konflikte auftreten, wird am Ende nach dem Prinzip „last write wins“ auf Basis des Zeitstempels entschieden.
  Aufgetretene Konflikte werden in einer speziellen Tabelle namens pgactive_conflict_history gespeichert, sodass sich die Historie nachvollziehen und Konflikte manuell lösen lassen.
  Weitere Details und die Dokumentation finden sich hier.
  • Es wird gefragt, ob das als Multi-Master-Replikation einzustufen ist.
    Falls eine solche Funktion offiziell in Postgres aufgenommen werden könnte, wäre das interessant.
  • Aus Sicht der Benutzer möchte man wissen, ob eigene Schreibvorgänge sofort bestätigt werden oder ob das System nur letztlich konvergiert.
• Es wird gefragt, ob jemand in letzter Zeit Bloombergs Datenbank comdb2 tatsächlich selbst verwendet hat.
• Etwas verwandt, aber leicht abseits des Themas, wird gefragt, ob es eine Möglichkeit für „lokal beschreibbare Replikation (auf Basis von Read Replicas)“ gibt.
  Zum Beispiel möchte man Daten aus Produktion oder Staging lesen, sie aber nur lokal ändern können, ohne dass die Ergebnisse wieder nach upstream zurückfließen, also gewissermaßen eine sekundäre Datenbank.
  Derzeit werden meistens per Skript (cron o. Ä.) Dumps oder Abfragen ausgeführt, daraus Snapshots erstellt, diese in S3 gespeichert und lokal wiederhergestellt.
  Das funktioniert meistens gut, aber manchmal dauert der Indexaufbau viel zu lange.
  • Zur Einordnung: Wegen personenbezogener oder anderer sensibler Daten wäre es riskant, Daten auf diese Weise direkt in Staging- oder Dev-Umgebungen zu bringen.
    Wegen großer rechtlicher und ethischer Risiken empfehlen die meisten Unternehmen dieses Vorgehen nicht.
  • Mit der logischen Replikation von Postgres plus Filtern ist eine unidirektionale Replikation möglich; wenn man einfach den Replikationsslot freigibt, kann man lokal frei Änderungen vornehmen.
    So lassen sich lokale Tabellen ändern, ohne dass das Primary beeinflusst wird.
  • Wenn man eine „saubere“ lokale Datenbank als Backup bereithält und diese bei Bedarf klont, um sie als Entwicklungsdatenbank zu verwenden, geht das Kopieren sehr schnell, ganz ohne erneuten Indexaufbau.
    Empfohlen wird der Befehl createdb --template.
  • Es wird gefragt, wie Konflikte behandelt werden, wenn lokale Schreibvorgänge mit Remote-Updates kollidieren.
    Eine Merge-Strategie, die für alle Situationen taugt, fällt nicht sofort ein.
  • Soweit bekannt, ist das bei der Einrichtung der logischen Replikation in Postgres das Standardverhalten.
    Schreiben auf dem Replica wird nicht blockiert; nur die Ergebnisse werden nicht an andere Orte weitergegeben.
• Man sollte sich immer bewusst machen, dass der Begriff „Conflict resolution“ letztlich bedeutet, bereits committete und bestätigte Daten zu verwerfen und damit die Haltbarkeit zu verletzen.
  Am besten entwirft man die Architektur so, dass sich die beschreibbaren Datenbereiche über alle aktiven Instanzen hinweg nicht überschneiden.
  In solchen Fällen kann ein Tool wie pgactive nützlich sein.
  Oder man nutzt von Anfang an gleich eine verteilte Datenbank wie Yugabyte.
  • Auch in der offiziellen Dokumentation wird zur Konfliktvermeidung empfohlen, die Schemas pro Master aufzuteilen, sodass „jeder Master der einzige Writer seines jeweiligen Schemas“ ist.
    Alle Master können zwar alle Schemas lesen, aber beim Schreiben ist jeder nur für seinen Bereich zuständig.
    Es wird gefragt, ob sich statt Schemas auch Partitionen oder Ähnliches zur Lastverteilung der Zuständigkeiten nutzen lassen.
• Das wirft die Frage auf, warum AWS das überhaupt gebaut hat.
  Ein direkter Einsatz in ihren eigenen Produkten fällt nicht sofort ein.
  RDS nutzt Block-Replikation, Aurora eine eigene SAN-Replikation.
  Vermutet wird, dass es vielleicht für DMS gedacht ist.
  • Vielleicht hängt es mit dem kürzlich eingeführten Aurora DSQL zusammen.
  • Der große praktische Nutzen ist nicht ganz ersichtlich.
    Es wird infrage gestellt, warum man das bei einer stark ACID-orientierten relationalen Datenbank überhaupt tun sollte.
  • Soweit bekannt, wird Auroras SAN-Replikation nicht für Cross-Region-Replikation verwendet.
  • Auch im README des Repositories steht ausdrücklich, dass der Hauptanwendungsfall der Aufbau eines hochverfügbaren Multi-Region-Datenbankclusters ist.
  • Tatsächlich soll die Funktion in RDS Postgres bereits seit zwei Jahren verfügbar gewesen sein (zugehöriger Link).
    Vor einem Monat gab es dann die Nachricht, dass sie offiziell als Open Source für die Community freigegeben wurde (offizielle Meldung).
• Ich habe mit repmgr und patroni mehrere Cluster in einer vollständig unterbrechungsfreien Umgebung betrieben, und dieses Plugin würde ich wirklich nur als allerletzte Option installieren wollen.
  Wenn ich nachts ruhig schlafen will, würde ich es möglichst vermeiden.
• Zufällig habe ich kürzlich nach einer einfachen Möglichkeit gesucht, einen hochverfügbaren Postgres-Cluster mit automatischem Failover, Node-Recovery und Point-in-Time-Recovery aufzubauen.
  Die Kombination aus patroni+etcd+haproxy wird oft empfohlen, und wenn Leute mit Praxiserfahrung so begeistert dazu raten, wird das wohl gute Gründe haben.
  Als ich mir aber Beispielkonfigurationen auf Basis von docker compose angesehen habe, wirkte das etwas abschreckend.
  pgpool scheint dagegen einfacher zu sein, weil man es offenbar nur vor jede Postgres-Instanz setzen muss.
  Mich interessieren Empfehlungen oder Erfahrungen von Leuten, die Postgres im echten Betrieb mögen und nutzen.
  Ziel ist es, auf Basis von docker compose möglichst einfach einen Cluster mit hoher Verfügbarkeit, mindestens ohne Datenverlust, und mit Point-in-Time-Recovery aufzubauen.
  • Es wird gefragt, ob damit nach einem Tool wie Barman gesucht wird.
  • Jemand nutzt cloudnativepg und sagt, dass damit die meisten benötigten Funktionen direkt funktionieren.
• Es werden noch weitere Materialien zu pgactive und verwandten Praxisfällen geteilt.
  <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
  Hacker-News-Beitrag (Beitrag von Oktober 2023, 1 Kommentar)
• Es scheint asynchron zu sein, und bei der Transaktionsisolation dürfte es erhebliche Probleme geben.
  • Letztlich ist es eben ein Trade-off.
    Das heißt, je nach Situation muss man die jeweiligen Vor- und Nachteile akzeptieren.