Sie können die Funktionen zur logischen Replikation und Decodierung in Cloud SQL for PostgreSQL verwenden. Diese Features ermöglichen logische Replikations-Workflows und Workflows für die Änderung von Datenerfassung (CDC).
Allgemeine Informationen zur Replikation finden Sie unter Replikation in Cloud SQL.
Einführung
Wenn PostgreSQL die logische Replikation ausführt, werden die an Replikate gestreamten Änderungen aus den WAL-Logs mithilfe der logischen Decodierung extrahiert. Die decodierten Änderungen sind unabhängig vom zugrunde liegenden physischen Speicherformat. Die Änderungen spiegeln nur die Änderungen an Daten auf SQL-Ebene in Bezug auf INSERTs, UPDATEs und DELETEs wider. Diese Unabhängigkeit von der Speicherebene bietet große Flexibilität und ermöglicht den Nutzern der Änderungsstreams eine breite Palette von Funktionen.
Die logische Replikation ist das Flag-Feature, das auf der logischen Decodierung basiert.
Im Gegensatz zum Feature Physische Replikation von PostgreSQL, bei dem die Quell- und Zieldatenbanken dieselbe Version haben müssen, ermöglicht die logische Replikation die Replikation über PostgreSQL-Hauptversionen. Die logische Replikation in Cloud SQL wird von der pglogical-Erweiterung unterstützt, die in allen PostgreSQL-Versionen verfügbar ist, sowie von der nativen logischen Replikation von PostgreSQL, die in PostgreSQL 10 hinzugefügt wird.
Das Format, in dem Änderungen gestreamt werden, kann mit verschiedenen Plug-ins konfiguriert werden. Dies ermöglicht flexible Architekturen zur Änderung von Daten (Change Data Capture, CDC).
Mit der Erweiterung wal2json können Sie beispielsweise alle Änderungen in einer Datenbank im JSON-Format streamen. Cloud SQL unterstützt den integrierten pgoutput-Decoder, das contrib-Modul test_decoding und wal2json. Cloud SQL unterstützt derzeit beide wal2json-Varianten der JSON-Ausgabe: format-version 1, was die gesamte Transaktion als einzelnes JSON-Objekt codiert, und format-version 2, was ein JSON-Objekt pro Befehl ausgibt. Diese Plug-ins ermöglichen die Replikation auf Nicht-PostgreSQL-Datenbanken.
PostgreSQL-Instanz konfigurieren
PostgreSQL unterstützt die logische Decodierung durch Schreiben zusätzlicher Informationen in sein Write-Ahead-Log (WAL).
In Cloud SQL aktivieren Sie dieses Feature, indem Sie das Flag cloudsql.logical_decoding auf on setzen. Diese Einstellung unterscheidet sich von der Einstellung in Standard-PostgreSQL.
Wenn Sie eine externe PostgreSQL-Instanz ändern, aktivieren Sie dieses Feature, indem Sie den Konfigurationsparameter wal_level auf logical setzen.
Wenn Sie die pglogical-Erweiterung verwenden möchten, muss pglogical zu shared_preload_libraries hinzugefügt werden. Da Cloud SQL keine direkte Änderung dieses Flags ermöglicht, wird pglogical aktiviert, indem cloudsql.enable_pglogical auf on gesetzt wird. (Auf einer VM, sudo apt-get install postgresql-13-pglogical) und starten Sie die Datenbank neu.
Wenn Sie pglogical für das Replikat zwischen zwei PostgreSQL-Instanzen verwenden, muss die logische Decodierung nur auf der primären Instanz und nicht auf der Replikatinstanz aktiviert werden, es sei denn, die Instanz selbst ist ein Primär für andere Replikate. Die pglogical-Erweiterung muss jedoch auf beiden Instanzen aktiviert sein. Beispiele für die Verwendung der Begriffe "primär" und "Replikat" und ihrer Bedeutung finden Sie unter Replikation in Cloud SQL.
Netzwerkverbindung aktivieren
Achten Sie darauf, dass Ihre primären Instanzen Verbindungen von der Replikatinstanz akzeptieren.
| Primär | Replikat | Konfiguration |
|---|---|---|
| Cloud SQL (öffentliche IP-Adresse) | Cloud SQL (öffentliche IP-Adresse) | Fügen Sie die ausgehende IP-Adresse des Replikats zu den autorisierten Netzwerken des primären Replikats hinzu. |
| Cloud SQL (Private IP-Adresse) | Cloud SQL (Private IP-Adresse) | Wenn sich beide Instanzen im selben Google Cloud-Projekt befinden, fügen Sie den
zugewiesenen IP-Bereich des VPC-Netzwerks des Replikats dem autorisierten Netzwerk hinzu, das die Instanzen hostet.
So finden Sie den zugewiesenen IP-Bereich in der Google Cloud Console:
|
| Extern | Cloud SQL | Sie können den Datenbank-Migrationsdienst verwenden. |
| Cloud SQL | Extern | Weitere Informationen finden Sie unter Externe Replikate konfigurieren. |
Ausgehende IP-Adresse einer Replikatinstanz abrufen
Wenn die Replikatinstanz eine Cloud SQL-Instanz mit einer öffentlichen IP-Adresse ist, führen Sie folgende Schritte aus, um die ausgehende IP-Adresse abzurufen.
Console
Öffnen Sie die Seite „Cloud SQL-Instanzen“.
Bewegen Sie den Mauszeiger neben der öffentlichen IP-Adresse des Cloud SQL-Replikats auf die Kurzinfo Weitere Informationen und rufen Sie die ausgehende IP-Adresse ab. Beachten Sie, dass die ausgehende IP-Adresse nicht die IP-Adresse ist, die in der Hauptliste für das Replikat in der Cloud Console angezeigt wird.
Wenn die Replikatinstanz keine Cloud SQL-Instanz ist, lesen Sie die entsprechende Dokumentation.
Weitere Informationen zum Abrufen der öffentlichen IP-Adresse einer Instanz finden Sie unter Ausgehende IP-Adresse des Cloud SQL-Replikats abrufen.
gcloud
Sie können den folgenden gcloud-Befehl verwenden:
gcloud sql instances describe [REPLICA_NAME] --format="default(ipAddresses)"
Verbindungen erlauben
Wenn die primäre Instanz eine Cloud SQL-Instanz ist, können Sie den Zugriff von der ausgehenden IP-Adresse des Replikats zulassen, indem Sie sie als autorisiertes Netzwerk hinzufügen.
Replikationsverbindungen für PostgreSQL 9.6 und niedriger aktivieren
Wenn Ihre primäre Instanz nicht in Cloud SQL ausgeführt wird und PostgreSQL 9.6 oder niedriger ausführt, muss die Datei pg_hba.conf
der Instanz so eingestellt sein, dass sie Replikationsverbindungen akzeptiert. Fügen Sie dieser Datei die folgende Zeile hinzu und verwenden Sie all all nur für den ersten Test. Für mehr Sicherheit beschränken Sie Nutzer und IP-Adressen auf die erforderlichen Elemente, wie in diesem Beispiel:
host replication all all md5
Weitere Informationen finden Sie in der Datei pg_hba.conf.
Replikationsnutzer erstellen
Erstellen Sie einen PostgreSQL-Nutzer mit dem Attribut REPLICATION, um logische Decodierungsfunktionen zu verwenden.
Beispiele
CREATE USER replication_user WITH REPLICATION
IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'secret';
Alternativ können Sie dieses Attribut für einen vorhandenen Nutzer festlegen:
ALTER USER existing_user WITH REPLICATION;
PostgreSQL-Ressourcen
Bei der logischen Decodierung wandelt ein Hintergrundprozess auf der primären PostgreSQL-Instanz WAL-Änderungen mithilfe des ausgewählten Decodierungs-Plug-ins in logische Änderungen um und leitet sie an einen Nutzer weiter, der sogar eine Nicht-PostgreSQL-Instanz sein kann. Dieser Hintergrundprozess wird als WAL-Sender bezeichnet. Die Anzahl der gleichzeitigen WAL-Sender, die in einer PostgreSQL-Instanz aktiv sein können, wird durch das Flag max_wal_senders begrenzt. Der Wert dieses Flags ist standardmäßig auf 10 und sein Limit wächst linear mit dem Arbeitsspeicher der Cloud SQL-Instanz, sodass acht WAL-Sender pro GB Arbeitsspeicher zugelassen werden.
Damit WAL-Segmente nicht verworfen werden, bevor sie an alle Nutzer gesendet werden, verwendet PostgreSQL logische Replikationsslots, um zu verfolgen, welche Daten an welchen Nutzer gesendet wurden, und physische Replikationsslots für Lesereplikate. Die Anzahl der Replikationsslots, die Sie für eine PostgreSQL-Instanz erstellen können, ist durch das Flag max_replication_slots begrenzt. Der Wert dieses Flags beträgt standardmäßig 10 und sein Limit wächst mit dem Arbeitsspeicher der Cloud SQL-Instanz, sodass zwischen 2 und 8 Replikationsslots pro GB Arbeitsspeicher möglich sind.
Die folgende Tabelle zeigt die Beziehung zwischen dem maximalen Arbeitsspeicher einer Cloud SQL-Instanz und der maximalen Anzahl an Replikationsslots für die Instanz.
Im Allgemeinen gibt es einen Replikationsslot und einen WAL-Sender pro Nutzer. Daher sollten diese Flags auf ungefähr identische Werte gesetzt werden. PostgreSQL empfiehlt jedoch, einen kleinen Puffer für max_wal_senders bereitzustellen, der verwendet werden kann, wenn Verbindungen unerwartet unterbrochen und neue Verbindungen hergestellt werden. Die physische Replikation, die von Cloud SQL-Lesereplikaten verwendet wird, verwendet auch einen Replikationsslot und einen WAL-Sender. Berücksichtigen Sie daher diese bei der Berechnung der benötigten Anzahl von Ressourcen.
Die native logische Replikation von PostgreSQL sowie pglogical erfordern die Ausführung zusätzlicher Hintergrundprozesse, sowohl auf der primären Instanz als auch auf der Replikatinstanz. Die Anzahl der Hintergrundprozesse, die ausgeführt werden können, ist durch das Flag max_worker_processes begrenzt. Die Standardeinstellung ist acht und das Limit wächst linear mit dem Arbeitsspeicher der Cloud SQL-Instanz, wodurch zwei zusätzliche Prozesse pro GB Arbeitsspeicher zugelassen werden. Die genaue Anzahl der Worker-Prozesse, die bei diesen Ansätzen verwendet werden, wird in den entsprechenden Abschnitten erläutert.
Wenn dieses Flag zu niedrig ist und die Replikation mit der Fehlermeldung worker registration failed in Ihren Logs fehlschlägt, müssen Sie möglicherweise die Einstellung max_worker_processes erhöhen.
Beachten Sie, dass WAL-Sender nicht als Worker-Prozesse zählen. Worker, die für die parallele Abfrageausführung erzeugt wurden, geben an, dass der Wert von max_worker_processes zu niedrig eingestellt ist. Dies kann die Leistung beeinträchtigen, da PostgreSQL die parallele Abfrageausführung nicht nutzen kann.
Mit der Funktion pg_ls_waldir () können Sie die WAL-Laufwerksnutzung ermitteln. Diese Funktion ist auf cloudsqlsuperuser-Nutzer wie den Standardadministratornutzer postgres beschränkt. Diese Funktion ist nur in PostgreSQL Version 10 und höher verfügbar.
So berechnen Sie die gesamte WAL-Laufwerksnutzung:
postgres=> select * from pg_ls_waldir();
| Name | Größe | Änderung |
|---|---|---|
| 00000001000000000000000A | 16777216 | 2021-08-11 15:16:49+00 |
| 000000010000000000000009 | 16777216 | 2021-08-12 06:23:24+00 |
(2 Zeilen)
postgres=> select pg_size_pretty(sum(size)) as "Total WAL disk usage" from pg_ls_waldir();
| WAL-Laufwerksnutzung gesamt |
|---|
| 32 MB |
(1 Zeile)
Logische Replikation mit externem Replikat einrichten
Ein komplettes Beispiel mit pglogischer und logischer Decodierung finden Sie unter Externe Replikate konfigurieren.
Logische Replikation mit pglogical einrichten
Zum Einrichten der logischen Replikation mit pglogical muss die logische Decodierung auf der primären Instanz aktiviert sein. Legen Sie cloudsql.logical_decoding=on für die Cloud SQL-Instanz oder wal_level=logical für eine externe Instanz fest. Darüber hinaus muss der pglogical sowohl in der primären als auch in der Replikatinstanz aktiviert sein; Legen Sie cloudsql.enable_pglogical=on auf einer Cloud SQL-Instanz fest oder fügen Sie pglogical zu shared_preload_libraries einer externen Instanz hinzu. Beachten Sie, dass bei einer Änderung dieser Flags sowohl die primäre Instanz als auch die Replikatinstanz neu gestartet werden müssen.
Wenn bei diesen Schritten Probleme auftreten, finden Sie unter Fehlerbehebung bei pglogical weitere Informationen.
Nutzer mit Replikationsberechtigungen erstellen
Sie benötigen einen Nutzer mit Replikationsberechtigungen und der Rolle cloudsqlsuperuser auf der primären Instanz und der Replikatinstanz, wenn Sie pglogical verwenden. Alle unten beschriebenen Befehle sollten von diesem Nutzer ausgeführt werden.
pglogical-Erweiterung installieren
Sie müssen die pglogical-Erweiterung sowohl auf der primären Instanz als auch auf der Replikatinstanz installieren. Auf dem primären Server muss der Replikationsnutzer (d. h. der Nutzer, der eine Verbindung zur Datenbank herstellt) installiert werden.
CREATE EXTENSION pglogical;
pglogical-Knoten auf jeder Instanz erstellen
Ein pglogical-Knoten stellt eine physische PostgreSQL-Instanz dar und speichert Verbindungsdetails für diese Instanz. Sowohl die primäre Instanz als auch die Replikatinstanz müssen sich als Knoten registrieren:
source-instance$ SELECT pglogical.create_node(
node_name := 'primary',
dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=secret'
);
dest-instance$ SELECT pglogical.create_node(
node_name := 'replica',
dsn := 'host=<replica-ip> port=5432 dbname=postgres user=replication_user password=secret'
);
Tabelle mit zu replizierenden Daten erstellen
Die pglogical-Erweiterung ermöglicht das Replizieren eines Teils der Tabellen an ein Ziel. Beispielsweise erstellen wir eine Dummy-Tabelle auf der primären Instanz und füllen sie mit zu testenden Daten:
CREATE TABLE replica_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO replica_test (data) VALUES ('apple'), ('banana'), ('cherry');
Die Tabelle muss auch auf der Replikatinstanz erstellt werden.
Tabelle zu einem Replikationssatz hinzufügen
Um die Replikation verschiedener Datasets an verschiedene Ziele zu unterstützen, hat pglogical das Konzept eines Replikations-Datasets. Sie können unsere Testtabelle dem Standardreplikationssatz hinzufügen.
SELECT pglogical.replication_set_add_table('default', 'replica_test', true);
pglogical-Abo erstellen
Erstellen Sie das pglogical-Abo für die Zielinstanz, indem Sie Verbindungsdetails für die primäre Instanz angeben.
SELECT pglogical.create_subscription(
subscription_name := 'test_sub',
provider_dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
);
SELECT * FROM pglogical.show_subscription_status('test_sub');
Wenn der Status "Replikat" angezeigt wird, ist die Einrichtung erfolgreich. Fragen Sie die Tabelle replica_test ab, um sicherzustellen, dass die Daten repliziert wurden. Fügen Sie Datensätze in die primäre Instanz ein und ändern Sie sie. Prüfen Sie dann, ob sie dann auf der Replikatinstanz angezeigt werden.
Fragen Sie in der primären Datenbank die Tabelle pg_replication_slots ab, um den vom Abo erstellten Replikationsslot abzurufen.
Clean-up
Nachdem der Test erfolgreich war, löschen Sie das Abo auf dem Replikat mit pglogical.drop_subscription('test_sub'). Prüfen Sie, ob der Replikationsslot auch auf der primären Instanz gelöscht wurde. Andernfalls akkumulieren WAL-Segmente auf der Replikatinstanz weiter.
Weitere Informationen zu Replikationssätzen, Teildatenreplikation, DDL-Replikation, anderen erweiterten Konfigurationen und Einschränkungen finden Sie in der pglogical-Dokumentation.
Ressourcennutzung
Die pglogical-Erweiterung führt mehrere Hintergrundprozesse aus, die auf das max_worker_processes-Limit angerechnet werden.
Im stabilen Zustand führt sie einen "Supervisor"-Prozess aus, wenn diese aktiviert ist, einen "Manager"-Prozess pro PostgreSQL-Datenbank, in der die Erweiterung installiert ist (z. B. können D hiervon vorhanden sein) und ein "apply"-Prozess pro pglogical-Abo auf der Replikatinstanz (z. B. könnte S davon vorhanden sein).
Die Erweiterung kann jedoch bei der ersten Synchronisierung zusätzliche Worker-Prozesse erzeugen und tatsächlich "Manager"-Prozesse für alle Datenbanken in der Instanz erzeugen. Wenn die Datenbank jedoch keine installierte Erweiterung hat, wird sie sofort beendet.
Weisen Sie daher einige weniger Worker-Prozesse zu als im stabilen Zustand erforderlich. Worker-Prozesse werden von PostgreSQL für andere Zwecke wie die parallele Abfrageverarbeitung verwendet. Wenn max_worker_processes zu niedrig ist, kann die Replikation im Hintergrund fehlschlagen oder PostgreSQL kann keine parallele Abfrageverarbeitung durchführen.
Zusammenfassung: Diese Einstellungen werden empfohlen:
max_worker_processes
>= 1 + D + 8 (on the source instance)
>= 1 + D + S + 8 (on the destination instance)
max_wal_senders >= S + 2 (on the source instance)
max_replication_slots >= S (on the source instance)
Fehler mit pglogical beheben
pglogical-Erweiterung kann nicht erstellt werden
Wenn Sie versuchen, die pglogical-Erweiterung zu installieren, wird möglicherweise folgender Fehler angezeigt:
ERROR: pglogical is not in shared_preload_libraries
Wenn Sie pglogical auf einer Cloud SQL-Instanz installieren, müssen Sie cloudsql.enable_pglogical=on festgelegt haben. Wenn Sie eine externe Instanz verwenden, fügen Sie sie direkt dem Flag shared_preload_libraries hinzu, z. B. shared_preload_libraries=pg_stat_statements,pglogical.
Diese Änderungen erfordern einen Neustart der primären Instanz.
pglogical-Abo konnte nicht erstellt werden
Beim Erstellen eines Abos prüft pglogical zuerst, ob es die Verbindungsdetails verwenden kann, um eine Verbindung zur Instanz herzustellen. Es wird zuerst versucht, eine reguläre Verbindung zu erstellen, und wenn dies fehlschlägt, wird ein Fehler ausgegeben: ERROR: could not
connect to the postgresql server.
Wenn dieser Fehler auftritt, prüfen Sie, ob die primäre Instanz so konfiguriert ist, dass Verbindungen von der Replikatinstanz zulässig sind. Prüfen Sie außerdem, ob die von Ihnen angegebenen Verbindungsdetails korrekt sind. Es werden zusätzliche Details bereitgestellt, warum PostgreSQL keine Verbindung herstellen konnte.
Nach dem Erstellen einer regulären Verbindung versucht pglogical, eine spezielle Replikationsverbindung herzustellen. In PostgreSQL 9.6 und früheren Versionen konnte diese Art von Verbindung eine andere Authentifizierungskonfiguration haben. Wenn der Fehler ERROR: could
not connect to the postgresql server in replication mode angezeigt wird, müssen Sie die Datei pg_hba.conf auf der Quellinstanz aktualisieren.
Die von Cloud SQL verwendete Datei pg_hba.conf enthält bereits die erforderlichen Änderungen. Dieser Fehler tritt nur auf, wenn eine Verbindung zu einer externen Instanz hergestellt wird, die nicht von Cloud SQL verwaltet wird.
Alternativ kann die Verbindung zum Replikationsmodus fehlschlagen, wenn die Quellinstanz nicht genügend WAL-Sender zulässt. Wenn FATAL: number of requested
standby connections exceeds max_wal_senders angezeigt wird, erhöhen Sie den Wert max_wal_senders auf der primären Instanz.
pglogical-Abo ist ausgefallen
Ein pglogical-Abo kann möglicherweise nicht repliziert werden. Um dieses Problem zu beheben, prüfen Sie zuerst, ob auf der Replikatinstanz ein Hintergrundprozess ausgeführt wird. Fragen Sie pg_stat_activity ab, um zu prüfen, ob ein pglogical apply-Prozess ausgeführt wird. Prüfen Sie andernfalls die Logs auf dem Zielknoten. Wenn die Meldung worker
registration failed, angezeigt wird, können Sie die Einstellung max_worker_processes erhöhen.
Prüfen Sie dann, ob in der primären Instanz ein Replikationsslot erstellt wurde. Auf der Replikatinstanz enthält die Zeile in pglogical.subscription den Namen des Slots, den das Abo erstellen soll. Auf der primären Instanz können Sie pg_replication_slots abfragen, um zu prüfen, ob der Slot erfolgreich erstellt.
Wenn kein Replikationsslot erstellt wurde, prüfen Sie die Logs auf der primären Instanz.
Der Fehler ERROR: logical decoding requires wal_level >= logical bedeutet, dass das Flag wal_level nicht auf logical festgelegt wurde. Dieses Problem können Sie beheben, indem Sie cloudsql.logical_decoding=on auf der primären Instanz festlegen, wenn es sich um eine Cloud SQL-Instanz handelt.
Wenn die Instanz eine externe Instanz ist, legen Sie wal_level=logical fest.
Andernfalls wird möglicherweise ERROR: all replication slots are in use und der hilfreiche HINT: Free one or increase max_replication_slots angezeigt.
Native logische PostgreSQL-Replikation einrichten
Ab PostgreSQL 10 unterstützt PostgreSQL die native logische Replikation. Zum Einrichten der nativen logischen Replikation muss die logische Decodierung auf der primären Instanz aktiviert sein. Dazu legen Sie für eine Cloud SQL-Instanz cloudsql.logical_decoding=on oder für eine externe Instanz wal_level=logical fest. Beachten Sie, dass bei einer Änderung dieser Flags ein Neustart der primären Instanz erforderlich ist.
Prüfen Sie, ob die Instanzen ordnungsgemäß konfiguriert sind (für die Netzwerkverbindung usw.), indem Sie die Abschnitte unter PostgreSQL-Instanz konfigurieren lesen. Diese Seite enthält die Schritte für ein Proof of Concept. Wenn bei den Schritten in diesen Abschnitten Probleme auftreten, finden Sie weitere Informationen unter Fehlerbehebung bei pglogical. Weitere Informationen finden Sie unter Logische Replikation in der PostgreSQL-Dokumentation.
Tabelle mit zu replizierenden Daten erstellen
Die logische PostgreSQL-Replikation unterstützt eine gesamte Datenbank oder nur einzelne Tabellen. Beispielsweise erstellen wir eine Dummy-Tabelle auf der primären Instanz und füllen sie zum Testen mit Daten.
CREATE TABLE native_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO native_test (data) VALUES ('apple'), ('banana'), ('cherry');
Die Tabelle muss auch auf der Replikatinstanz erstellt werden.
Publikation auf der primären Instanz erstellen
Native logische Log-Replikation bezieht sich auf Publisher und Abonnenten.
Erstellen Sie eine Publikation der Daten in native_test:
CREATE PUBLICATION pub FOR TABLE native_test;
Abo auf der Replikatinstanz erstellen
Hier ist ein Beispiel für das Erstellen eines Abos auf der Replikatinstanz:
CREATE SUBSCRIPTION sub
CONNECTION 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
PUBLICATION pub;
Zum Erstellen des Abos auf der Replikatinstanz ist die Rolle cloudsqlsuperuser erforderlich. Nachdem Sie das Abo erstellt haben, können Sie die Tabelle native_test abfragen, um zu prüfen, ob die Daten in der Replikatinstanz angezeigt wurden.
In der primären Datenbank können Sie die Tabelle pg_replication_slots abfragen, um den vom Abo erstellten Replikationsslot anzuzeigen.
Clean-up
Wenn der Test erfolgreich ist, löschen Sie das Abo auf dem Replikat mit DROP
SUBSCRIPTION sub;. Prüfen Sie, ob der Replikationsslot auch auf der primären Instanz gelöscht wurde. Andernfalls werden sich WAL-Segmente auf der primären Instanz weiterhin angesammelt.
Einschränkungen bei der logischen PostgreSQL-Replikation
Der Zugriff auf die Spalte subconninfo der Systemtabelle pg_subscription ist nicht verfügbar.
Wenn Sie pg_dump ausführen, können keine Informationen zu Abos abgerufen werden, da geprüft wird, ob der Nutzer, der die Verbindung herstellt, Superuser-Berechtigungen hat.
Decodierte WAL-Änderungen für die Change Data Capture (CDC) empfangen
Als alternativer Anwendungsfall für CDC kann die logische Decodierung Änderungen von einer PostgreSQL-Instanz streamen. Das dafür verwendete Standardtool ist pg_recvlogical.
Mit dem pg_recvlogical-Tool können Sie einen Replikationsslot erstellen und die von diesem Slot erfassten Änderungen streamen. Das Format der Änderungen hängt von der ausgewählten Codierungs-Plug-in ab. Sie können Folgendes angeben:
wal2json, um im JSON-Format formatierte Änderungen zu streamen, oder
test_decoding, um Änderungen zu streamen, die mit einem Bare-Text-Format formatiert sind
Replikationsslot erstellen
Führen Sie folgenden Befehl aus, um einen Replikationsslot zu erstellen:
pg_recvlogical
-h <instance_ip> \
-U <replication_user> \
-p 5432 \
-d postgres \
--slot test_slot \
--create-slot \
-P <decoder_plugin>
Streamänderungen
Führen Sie in einem Cloud Shell-Terminal folgenden Befehl aus:
pg_recvlogical
-h <instance_ip> \
-U <replication_user> \
-p 5432 \
-d postgres \
--slot test_slot \
--start \
-f -
Stellen Sie in einem anderen Cloud Shell-Terminal eine Verbindung zu Ihrer Datenbank her und führen Sie folgende Befehle aus:
CREATE TABLE cdc_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO cdc_test (data) VALUES ('apple', 'banana');
UPDATE cdc_test SET data = 'cherry' WHERE id = 2;
DELETE FROM cdc_test WHERE id = 1;
DROP TABLE cdc_test;
Wenn Sie das Decoder-Plug-in wal2json verwenden, wird im ersten Cloud Shell-Terminal eine Ausgabe wie die folgende angezeigt:
{"change":[]}
{"change":[{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[1,"apple"]},{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"banana"]}]}
{"change":[{"kind":"update","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"cherry"],"oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[2]}}]}
{"change":[{"kind":"delete","schema":"public","table":"cdc_test","oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[1]}}]}
{"change":[]}
Wenn Sie das Decoder-Plug-in test_decoding verwenden, wird im ersten Cloud Shell-Terminal eine Ausgabe wie die folgende angezeigt:
BEGIN 19460
COMMIT 19460
BEGIN 19461
table public.cdc_test: INSERT: id[integer]:1 data[text]:'apple'
table public.cdc_test: INSERT: id[integer]:2 data[text]:'banana'
COMMIT 19461
BEGIN 19462
table public.cdc_test: UPDATE: id[integer]:2 data[text]:'cherry'
COMMIT 19462
BEGIN 19463
table public.cdc_test: DELETE: id[integer]:1
COMMIT 19463
BEGIN 19464
COMMIT 19464
Ihre Transaktions-IDs können abweichen.
Clean-up
Löschen Sie nach Abschluss des Tests den von Ihnen erstellten Replikationsslot mit folgendem Befehl:
pg_recvlogical
-h <instance_ip> \
-U <replication_user> \
-p 5432 \
-d postgres \
--slot test_slot \
--drop-slot
Hinweise und Einschränkungen
Die Hinweise und Einschränkungen in diesem Abschnitt gelten für die logischen Replikations- und Decodierungsfunktionen von Cloud SQL for PostgreSQL.
Wenn Sie eine Instanz wiederherstellen, in der
cloudsql.logical_decodingodercloudsql.enable_pglogicalaktiviert ist und die derzeit als Publisher für die logische Replikation fungiert, müssen Sie die Replikation zuerst auf alle Zielinstanzen deaktivieren. Andernfalls schlägt die Wiederherstellung in der Instanz mit einem Fehler fehl, derzeit sind jedoch die Details des Fehlers nicht sichtbar.Wenn Sie eine Sicherung einer Instanz wiederherstellen, in der
cloudsql.logical_decodingodercloudsql.enable_pglogicalzum Zeitpunkt der Sicherung aktiviert war und Sie diese in einer neuen Instanz wiederherstellen, wird der Replikationsstatus nicht in der neuen Instanz wiederhergestellt. Sie müssen die Replikation anschließend manuell neu konfigurieren.Auf einer Cloud SQL-Instanz mit einem oder mehreren Cloud SQL-Lesereplikaten (durch physische Replikation) werden diese Flags auch auf dem Lesereplikat aktiviert, wenn Sie
cloudsql.logical_decodingodercloudsql.enable_pglogicalaktivieren.Cloud SQL-Lesereplikate können nicht als Publisher für die logische Replikation genutzt werden, da PostgreSQL die logische Decodierung in Lesereplikaten nicht unterstützt. Die Flags sind jedoch auf der Lesereplikatinstanz aktiviert, damit sie bei einem Hochstufen als Ersatz für die primäre Instanz dienen kann.
Wenn Sie
cloudsql.logical_decodingodercloudsql.enable_pglogicalauf der primären Instanz aktivieren, werden die Flags auf allen Lesereplikaten aktiviert. Dies führt dazu, dass die primären und Lesereplikate kurz nacheinander neu gestartet werden. Um diese Situation zu vermeiden und zu steuern, wann jede Instanz neu gestartet wird, können Sie (1) die Flags auf jedem Lesereplikat nacheinander festlegen und nur dann (2) die Flags auf der primären Instanz festlegen.Das Deaktivieren von
cloudsql.logical_decodingodercloudsql.enable_pglogicalauf der primären Instanz führt nicht dazu, dass die Flags auf allen Lesereplikaten deaktiviert werden. Um die Flags in den Instanzen zu deaktivieren, müssen Sie den umgekehrten Vorgang des oben beschriebenen Vorgangs ausführen: (1) Deaktivieren Sie die Flags auf der primären Instanz und (2) deaktivieren Sie die Flags wiederum auf jedem Lesereplikat.