Die pglogical-Erweiterung

Auf dieser Seite erhalten Sie einen Überblick über die pglogical-Erweiterung, ihre Vorteile und Einschränkungen.

Übersicht

Die pglogical-Erweiterung ist ein robustes und flexibles Tool zur logischen Replikation, das für PostgreSQL entwickelt wurde. Außerdem unterstützt es Hochverfügbarkeit (HA) und Notfallwiederherstellung (DR).

Bei der traditionellen binären Replikation, auch als physische Replikation bezeichnet, werden Änderungen auf Dateisystem- und Blockebene repliziert, was zu einem physischen Spiegel im Zielsystem führt. Die physische Replikation ist zwar robust und schützt den gesamten Datenbankcluster, sie ist jedoch nur einseitig und erfordert Zugriff auf die zugrunde liegende Datenbankdatendatei und die Write-Ahead-Log-Dateien (WAL).

Die Erweiterung pglogical hingegen extrahiert SQL-Änderungen aus einer Anbieterdatenbank, repliziert sie und spielt sie dann in einer oder mehreren Abonnentendatenbanken ab. Diese Replikation wird als logische Replikation bezeichnet.

Mit der pglogical-Erweiterung können Sie Folgendes tun:

  • Daten zwischen mehreren AlloyDB Omni-Datenbanken replizieren.
  • Daten zwischen AlloyDB Omni und Google Cloud AlloyDB replizieren
  • Daten zwischen AlloyDB Omni und anderen PostgreSQL-Distributionen replizieren, darunter viele in Cloud-Diensten von Drittanbietern

Vorteile

Die logische Replikation mit der pglogical-Erweiterung bietet folgende Vorteile:

  • Selektive Replikation:Sie können Filter und Regeln festlegen, um zu bestimmen, welche Daten und wo sie repliziert werden sollen. Sie können auswählen, welche Tabellen eingeschlossen werden sollen und wie neue Tabellen behandelt werden, unabhängig davon, ob sie eingeschlossen werden oder nicht. Sie können auch Spalten- und Zeilenfilter hinzufügen. Optional kann ein apply delay hinzugefügt werden, wenn der Abonnent einen bestimmten Zeitpunkt des Anbieters repräsentieren soll.

  • Bidirektionale und mehrstufige Replikation:Alle Mitgliedsdatenbanken sind im Lese-/Schreibstatus geöffnet und voll funktionsfähig. Jede Endpunktdatenbank fungiert sowohl als Anbieter als auch als Abonnent. So können erweiterte Replikationsszenarien erstellt und Daten an verschiedenen Endpunkten aktualisiert werden.

  • Cloud-Anbieterunterstützung:Cloud-Anbieter wie Google erkennen den Wert der pglogical-Erweiterung und integrieren sie in ihre Cloud-Dienste wie Google Cloud SQL for PostgreSQL und AlloyDB. Andere Cloud-Anbieter bieten die pglogical-Erweiterung ebenfalls als Option an, was Multi-Cloud- oder Hybrid-Cloud-Konfigurationen ermöglicht.

  • Versionsübergreifende Replikation:Da pglogical die tatsächlichen SQL-Anweisungen repliziert, ist die Replikation zwischen den Hauptversionen von PostgreSQL möglich. Insbesondere wenn die Quelldatenbank des Anbieters eine niedrigere Version als die Zieldatenbank des Abonnenten hat, kann die versionübergreifende Replikation zuverlässig implementiert werden.

    Die pglogical-Erweiterung bietet Unterstützung für viele ältere PostgreSQL-Versionen, z. B. Version 9.4 und höher. Das macht es zur optimalen Wahl für Szenarien, in denen Sie mit Legacy-Systemen arbeiten und Daten in modernere PostgreSQL-Versionen replizieren möchten, z. B. solche, die in AlloyDB Omni und Google Cloud AlloyDB verwendet werden.

Zusammenfassend bietet die pglogical-Erweiterung eine funktionsreiche Lösung für die logische Replikation mit Kompatibilität für ältere Versionen von PostgreSQL und verwaltete Cloud-Dienste wie Google Cloud SQL for PostgreSQL und AlloyDB.

Einschränkungen der logischen Replikation

Alle Technologien zur logischen Replikation, einschließlich derjenigen, die mit anderen relationalen Datenbankplattformen verwendet werden, haben einige Einschränkungen. Eine unsachgemäße Verwaltung kann den Replikationsprozess beeinträchtigen.

Beachten Sie für eine zuverlässige Implementierung die folgenden Punkte:

  • Informationen zum Umgang mit objekten auf Datenbank- und Clusterebene, die nicht zum Replikationsumfang gehören. Die pglogical-Erweiterung funktioniert nur auf Datenbankebene und nur für eine bestimmte Gruppe von Tabellen und Sequenzen. Andere Objekttypen wie Funktionen und Prozeduren müssen mit einer anderen Methode repliziert werden.
  • Es wird empfohlen, dass alle Replikationstabellen einen Primärschlüssel haben. Mit der Tabellenfunktion REPLICA IDENTITY können Sie der pglogical-Erweiterung mitteilen, mit welchen Spalten die Zeilen eindeutig identifiziert werden. Das sollte nach Möglichkeit vermieden werden. Tabellen ohne Primärschlüssel sind statisch, sind niemals UPDATED oder DELETED und unterstützen nur INSERTS. Für diese Tabellentypen sind keine Primärschlüssel erforderlich.
  • Verwaltung von Triggern und Sequenzen in Abonnentendatenbanken. Standardmäßig sind Trigger als ORIGIN- oder LOCAL-Trigger definiert und werden nicht in der Abonnentendatenbank ausgelöst, wenn die Zeilen repliziert werden. Prüfe alle Trigger, um sicherzustellen, dass die Option REPLICA für jeden Trigger festgelegt ist, damit er nur dann ausgelöst wird, wenn es erforderlich ist.
  • Konfliktlösung entweder manuell oder automatisch über who wins-Regeln
  • Replikation von DDL-Befehlen (Data Definition Language) durch manuelle Implementierung auf allen Endpunkten oder automatische Replikation von DDL in Abonnentendatenbanken mithilfe der entsprechenden pglogical API-Funktion in der Anbieterdatenbank.
  • Sorgen Sie dafür, dass neu erstellte Tabellen und Sequenzen manuell oder automatisch Replikationssätzen in primären Datenbanken hinzugefügt werden.
  • Sorgen Sie dafür, dass zwischen allen Endpunkten in der Replikationstopologie ein robustes, leistungsstarkes, zuverlässiges und sicheres TCP-Netzwerk vorhanden ist.

Weitere Einschränkungen der pglogical-Erweiterung:

  • Für pglogical Version 2.4.3 sind derzeit Superuser-Berechtigungen erforderlich.
  • Die meisten Tabellen und Sequenzen können repliziert werden, andere Objekttypen werden jedoch nicht von der pglogical-Erweiterung repliziert. Auch TEMPORARY- und UNLOGGED-Tabellen werden nicht repliziert.
  • Zum Replizieren von DDL muss die pglogical API-Funktion verwendet werden. Native DDL-Befehle werden nicht repliziert, mit Ausnahme des Befehls TRUNCATE.
  • Wird auf Objektebene pro Tabelle und pro Sequenz ausgeführt und pro Datenbank bereitgestellt. Das bedeutet, dass einige Objekte, einschließlich clusterbezogener Objekte wie users und roles, von der Replikation ausgeschlossen sind und separat verwaltet werden müssen.

Nächste Schritte