Die pglogical-Erweiterung ist ein robustes und flexibles Tool für die logische Replikation, das für PostgreSQL entwickelt wurde und auch Hochverfügbarkeit und Notfallwiederherstellung unterstützt.
Bei der herkömmlichen binären Replikation, die auch als physische Replikation bezeichnet wird, werden Änderungen auf Dateisystem- und Blockebene repliziert. Dadurch entsteht ein physischer Spiegel im Zielsystem. Die physische Replikation ist zwar robust und schützt den gesamten Datenbankcluster, sie ist aber nur unidirektional und erfordert Zugriff auf die zugrunde liegenden Datenbankdatendateien und Write-Ahead-Log-Dateien (WAL).
Die Erweiterung pglogical 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, einschließlich vieler 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 repliziert werden sollen und wohin. Sie können auswählen, welche Tabellen einbezogen werden sollen und wie neue Tabellen behandelt werden sollen, unabhängig davon, ob sie einbezogen werden oder nicht.
Sie können auch Spalten- und Zeilenfilter hinzufügen. Optional kann apply delay hinzugefügt werden, wenn der Abonnent einen bestimmten Zeitpunkt in der Vergangenheit des Anbieters repräsentieren soll.
Bidirektionale und Multi-Primary-Replikation:Alle Mitgliedsdatenbanken sind im Lese-/Schreibmodus geöffnet und können vollständig verwendet werden. Jede Endpunktdatenbank fungiert sowohl als Anbieter als auch als Abonnent, was die Erstellung komplexer Replikationsszenarien und Datenaktualisierungen an verschiedenen Endpunkten ermöglicht.
Unterstützung durch Cloud-Anbieter: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 Hauptversionen von PostgreSQL möglich. Insbesondere wenn die Quelldatenbank des Anbieters eine niedrigere Version als die Zieldatenbank des Abonnenten hat, kann die versionsübergreifende Replikation zuverlässig implementiert werden.
Die Erweiterung pglogical bietet Unterstützung für viele frühere Versionen von PostgreSQL, z. B. Version 9.4 und höher. Daher ist es eine optimale Wahl für Szenarien, in denen Sie mit Legacy-Systemen arbeiten und Daten in modernere Versionen von PostgreSQL replizieren möchten, z. B. in die Versionen, die in AlloyDB Omni und Google Cloud AlloyDB verwendet werden.
Zusammenfassend lässt sich sagen, dass die pglogical-Erweiterung eine funktionsreiche Lösung für die logische Replikation bietet, die mit älteren Versionen von PostgreSQL und Cloud-verwalteten Diensten wie Google Cloud SQL for PostgreSQL und AlloyDB kompatibel ist.
Einschränkungen der logischen Replikation
Alle Technologien für die logische Replikation, einschließlich der Technologien, die mit anderen relationalen Datenbankplattformen verwendet werden, haben einige Einschränkungen. Eine falsche Verwaltung kann den Replikationsprozess unterbrechen.
Beachten Sie die folgenden Punkte für eine zuverlässige Implementierung:
Überlegungen zum Umgang mit datenbankbezogenen und clusterbezogenen Objekten, die außerhalb des Replikationsbereichs liegen. Die pglogical-Erweiterung funktioniert auf Datenbankebene und nur für einen bestimmten Satz 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 Funktion REPLICA IDENTITY der Tabelle können Sie der Erweiterung pglogical mitteilen, welche Spalten die Zeilen eindeutig identifizieren. Das sollte nach Möglichkeit vermieden werden. Tabellen ohne Primärschlüssel sind statisch und werden nie UPDATED oder DELETED. Sie unterstützen nur INSERTS.
Für diese Tabellentypen sind keine Primärschlüssel erforderlich.
Verwaltung von Triggern und Sequenzen in Abonnentendatenbanken. Standardmäßig werden Trigger als ORIGIN- oder LOCAL-Trigger definiert und werden nicht in der Abonnentendatenbank ausgelöst, wenn die Zeilen repliziert werden. Alle Trigger sollten geprüft werden, um sicherzustellen, dass die Option REPLICA für jeden Trigger festgelegt ist, damit er nicht auf der Abonnentenseite ausgelöst wird, es sei denn, dies ist erforderlich.
Konflikte manuell oder automatisch mithilfe von who wins-Regeln beheben.
Replikation von DDL-Befehlen (Data Definition Language) durch manuelle Implementierung auf allen Endpunkten oder automatische Replikation von DDL in Abonnentendatenbanken mit der entsprechenden pglogical-API-Funktion in der Anbieterdatenbank.
Sorgen Sie dafür, dass neu erstellte Tabellen und Sequenzen manuell oder automatisch Replikationssets in primären Datenbanken hinzugefügt werden.
Sorgen Sie dafür, dass ein robustes, leistungsstarkes, zuverlässiges und sicheres TCP-Netzwerk zwischen allen Endpunkten in der Replikationstopologie vorhanden ist.
Für die pglogical-Erweiterung gelten die folgenden zusätzlichen Einschränkungen:
Für pglogical Version 2.4.3 sind Superuser-Berechtigungen erforderlich.
Die meisten Tabellen und Sequenzen können repliziert werden, andere Objekttypen jedoch nicht. Die Tabellen TEMPORARY und UNLOGGED werden nicht repliziert.pglogical
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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThe \u003ccode\u003epglogical\u003c/code\u003e extension is a logical replication tool for PostgreSQL that supports high availability, disaster recovery, and allows for replication between multiple AlloyDB Omni databases and other PostgreSQL distributions.\u003c/p\u003e\n"],["\u003cp\u003eLogical replication with \u003ccode\u003epglogical\u003c/code\u003e offers benefits such as selective replication, bi-directional and multi-primary replication, cloud provider support, and cross-version replication.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003epglogical\u003c/code\u003e works by replicating SQL changes from a provider database to one or more subscriber databases, offering more flexibility than traditional physical replication.\u003c/p\u003e\n"],["\u003cp\u003eWhile powerful, \u003ccode\u003epglogical\u003c/code\u003e has limitations, including the requirement for primary keys on most replicated tables, the manual management of certain database objects, and the need for careful handling of triggers and DDL commands.\u003c/p\u003e\n"],["\u003cp\u003eThe use of \u003ccode\u003epglogical\u003c/code\u003e requires a robust, secure TCP connection between all the endpoints in the replication topology.\u003c/p\u003e\n"]]],[],null,["# About the pglogical extension\n\nSelect a documentation version: 15.5.5keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/about-pglogical)\n- [16.8.0](/alloydb/omni/16.8.0/docs/about-pglogical)\n- [16.3.0](/alloydb/omni/16.3.0/docs/about-pglogical)\n- [15.12.0](/alloydb/omni/15.12.0/docs/about-pglogical)\n- [15.7.1](/alloydb/omni/15.7.1/docs/about-pglogical)\n- [15.7.0](/alloydb/omni/15.7.0/docs/about-pglogical)\n- [15.5.5](/alloydb/omni/15.5.5/docs/about-pglogical)\n- [15.5.4](/alloydb/omni/15.5.4/docs/about-pglogical)\n- [15.5.2](/alloydb/omni/15.5.2/docs/about-pglogical)\n\n\u003cbr /\u003e\n\nThis page provides an overview of the `pglogical` extension, its benefits, and limitations.\n\n\u003cbr /\u003e\n\n\n| The information on this page applies only to AlloyDB Omni for containers. It does not apply to AlloyDB Omni for Kubernetes.\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nThe [`pglogical` extension](https://github.com/2ndQuadrant/pglogical) is a robust and flexible\nlogical replication tool designed for PostgreSQL, and it also supports\nhigh availability (HA) and disaster recovery (DR).\n\nTraditional binary replication, commonly known as *physical replication*, replicates\nchanges at the file system and block level, resulting in a physical mirror in the\ntarget system. Even though the physical replication is robust and protects the\nentire database cluster, it is unidirectional only and requires access to the\nunderlying database data file and write-ahead log (WAL) files.\n\nWhereas, the `pglogical` extension extracts SQL changes from a provider\ndatabase and replicates them, and then replays them against one or more subscriber\ndatabases. This replication is known as *logical replication*.\n| **Note:** The `pglogical` extension uses the terms `provider` and `subscriber` to describe the endpoints that are used in a replication topology. These terms are synonyms for terms such as source/target, publisher/subscriber, and primary/standby.\n\nBy using the `pglogical` extension, you can do the following:\n\n- Replicate data between multiple AlloyDB Omni databases.\n- Replicate data between AlloyDB Omni and Google Cloud AlloyDB.\n- Replicate data between AlloyDB Omni and other PostgreSQL distributions that include many in third-party cloud services.\n\nBenefits\n--------\n\nLogical replication with the `pglogical` extension offers the following benefits:\n\n- **Selective replication:** provides the flexibility to set filters and rules\n to determine what data you want to replicate and where to. You can choose which\n tables are included and how new tables are handled whether they're included or not.\n You can also add column and row filters. An optional `apply delay`\n can be added for situations where you want the subscriber to represent some\n trailing point in time from the provider.\n\n- **Bi-directional and multi-primary replication:** all member databases are open\n in a read/write state and are fully usable. Each endpoint database acts as both\n provider and subscriber, allowing the creation of advanced replication scenarios,\n and enabling the possibility of data updates that are made at different endpoints.\n\n- **Cloud provider support:** Cloud providers such as Google recognize the value\n of the `pglogical` extension and integrate it into their Cloud services,\n such as Google Cloud SQL for PostgreSQL and AlloyDB. Other cloud\n providers also include the `pglogical` extension as an option, allowing multi-cloud\n or hybrid-cloud configurations.\n\n- **Cross-version replication:** as pglogical replicates the actual SQL statements,\n it allows replication between major versions of PostgreSQL. Especially when the\n provider source database is a lower version than the subscriber target database,\n cross-version replication can be implemented with reliability.\n\n The `pglogical` extension offers support for many earlier versions of PostgreSQL\n such as version 9.4 and higher. This makes it an optimal choice for scenarios\n where you are dealing with legacy systems and want to replicate data into more\n modern versions of PostgreSQL such as those used in AlloyDB Omni\n and Google Cloud AlloyDB.\n\nIn summary, the `pglogical` extension provides a feature-rich logical replication\nsolution, with compatibility for older versions of PostgreSQL and Cloud-managed\nservices that include Google Cloud SQL for PostgreSQL and AlloyDB.\n\nLimitations of logical replication\n----------------------------------\n\nAll logical replication technologies, including those used with other\nrelational database platforms, have some limitations, and any mismanagement can\nbreak the replication process.\n\nConsider the following points for a reliable implementation:\n\n- Consideration on how to handle database-scoped and cluster-scoped objects that are outside of the replication scope. The `pglogical` extension works at the database level and against a specified set of tables and sequences only. Other object types, such as functions and procedures, must be replicated using some other method.\n- It is recommended that all replication tables must have a primary key. It is possible to utilize the table `REPLICA IDENTITY` feature to inform the `pglogical` extension about which columns uniquely identify the rows. This must be avoided where possible. Tables that do not have primary keys, are static in nature, and are never `UPDATED` or `DELETED`, and supports only `INSERTS`. These types of tables do not need primary keys.\n- Management of triggers and sequences in subscriber databases. By default, triggers are defined as `ORIGIN` or `LOCAL` triggers, and do not fire on the subscriber database when the rows are replicated. All triggers should be checked to ensure that the `REPLICA` option is set for any trigger so that it does not fire on the subscriber end unless it is required.\n- Dealing with conflict resolution either manually or automatically through `who wins` rules.\n- Replication of Data Definition Language (DDL) commands by either manually implementing on all endpoints, or automatically replicating DDL to subscriber databases using the appropriate `pglogical` API function on the provider database.\n- Ensuring that newly created tables and sequences are manually or automatically added to replication sets on primary databases.\n- Ensuring that a robust, performant, reliable, and secured TCP network exists between all endpoints in the replication topology.\n\nAdditional restrictions and limitations of the `pglogical` extension include the\nfollowing:\n\n- Superuser permissions are required for `pglogical` version 2.4.3.\n- While most tables and sequences can be replicated, other object types are not replicated by the `pglogical` extension, and `TEMPORARY` and `UNLOGGED` tables are not replicated.\n- To replicate DDL, the pglogical API function must be used. Native DDL commands are not replicated, except for the `TRUNCATE` command.\n- Operates on an object level per table and per sequence, and is deployed per database. This means that some objects, including cluster-scoped objects such as `users` and `roles`, are excluded from the replication and must be managed separately.\n\nWhat's next\n-----------\n\n- [Replicate data between AlloyDB for PostgreSQL and AlloyDB Omni](/alloydb/omni/15.5.5/docs/replicate-data-alloydb-omni).\n- [Replicate data between AlloyDB Omni and other databases](/alloydb/omni/15.5.5/docs/replicate-data-omni-other-db)."]]
