Logische Replikation und Decodierung in Azure Database for PostgreSQL – Flexible Server

Azure Database for PostgreSQL – Flexibler Server unterstützt die folgenden Methoden der logischen Datenextraktion und -replikation:

1. Logische Replikation

   1. Verwendung Sie PostgreSQL native logische Replikation, um Datenobjekte zu replizieren. Die logische Replikation bietet Ihnen eine differenzierte Kontrolle über die Datenreplikation, einschließlich der Datenreplikation auf Tabellenebene.
   2. Verwenden der pglogical-Erweiterung , die die logische Streamingreplikation und weitere Funktionen bereitstellt, z. B. kopieren des anfänglichen Schemas der Datenbank, Unterstützung für TRUNCATE, Möglichkeit zum Replizieren von DDL und mehr.

2. Logische Decodierung , die durch Decodieren des Inhalts des Write-Ahead-Protokolls (WAL) implementiert wird.

Vergleichen der logischen Replikation und der logischen Decodierung

Die logische Replikation und die logische Decodierung weisen Ähnlichkeiten auf. Beide:

• Ermöglichen es Ihnen, Daten aus Postgres zu replizieren.

• Verwenden das Write-Ahead-Protokoll (Write-Ahead Log, WAL) als Änderungsquelle.

• Verwenden logische Replikationsslots, um Daten zu senden. Ein Slot stellt einen Datenstrom von Änderungen dar.

• Bestimmen mithilfe der Eigenschaft „REPLICA IDENTITY“ einer Tabelle, welche Änderungen gesendet werden können.

• Replizieren Sie keine DDL-Änderungen.

Die beiden Technologien unterscheiden sich wie folgt:

Logische Replikation:

• Ermöglicht es Ihnen, eine Tabelle oder Tabellengruppe anzugeben, die repliziert werden soll.

Die logische Decodierung:

• Extrahiert Änderungen aus allen Tabellen in einer Datenbank.

Voraussetzungen für die logische Replikation und die logische Decodierung

1. Wechseln Sie zur Parameterseite im Portal.

2. Setzen Sie den Parameter wal_level auf logical.

3. Wenn Sie eine pglogical-Erweiterung verwenden möchten, suchen Sie nach den Parametern shared_preload_libraries und azure.extensions und wählen Sie pglogical aus dem Dropdown-Listenfeld aus.

4. Ändern Sie den Wert des Parameters max_worker_processes mindestens in 16. Andernfalls könnte es zu Problemen wie WARNING: out of background worker slots kommen.

5. Speichern Sie die Änderungen, und starten Sie den Server neu, um die Änderung zu übernehmen.

6. Vergewissern Sie sich, dass Ihr Azure Database for PostgreSQL flexibler Server Netzwerkdatenverkehr von Ihrer Verbindungsressource zulässt.

7. Erteilen Sie dem Administratorbenutzer Replikationsberechtigungen.

   ALTER ROLE <adminname> WITH REPLICATION;
   

8. Stellen Sie sicher, dass die von Ihnen verwendete Rolle über Berechtigungen für das Schema verfügt, das Sie replizieren. Andernfalls können Fehler wie Permission denied for schema auftreten.

Verwenden der logischen Replikation und der logischen Decodierung

Die Verwendung der nativen logischen Replikation ist die einfachste Möglichkeit, Daten aus Ihrem Azure Database for PostgreSQL flexiblen Server zu replizieren. Sie können die SQL-Schnittstelle oder das Streamingprotokoll verwenden, um die Änderungen zu verarbeiten. Sie können auch die SQL-Schnittstelle verwenden, um Änderungen mithilfe der logischen Decodierung zu nutzen.

Native logische Replikation

Die logische Replikation verwendet die Begriffe Herausgeber und Abonnent.

• Der Publisher ist die Azure Database for PostgreSQL Flexible Server-Datenbank, die Daten sendet.
• Der Abonnent ist die Azure Database for PostgreSQL flexible Serverdatenbank, die Daten empfängt.

Nachstehend finden Sie einen Beispielcode, mit dem Sie die logische Replikation ausprobieren können.

1. Stellen Sie eine Verbindung mit der Verlegerdatenbank her. Erstellen Sie eine Tabelle, und fügen Sie Daten hinzu.

   CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);
   INSERT INTO basic VALUES (1, 'apple');
   INSERT INTO basic VALUES (2, 'banana');
   

2. Erstellen Sie eine Veröffentlichung für die Tabelle.

   CREATE PUBLICATION pub FOR TABLE basic;
   

3. Stellen Sie eine Verbindung mit der Abonnentendatenbank her. Erstellen Sie eine Tabelle mit demselben Schema wie für den Verleger.

   CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);
   

4. Erstellen Sie ein Abonnement, das eine Verbindung mit der zuvor erstellten Veröffentlichung herstellt.

   CREATE SUBSCRIPTION sub CONNECTION 'host=<server>.postgres.database.azure.com user=<rep_user> dbname=<dbname> password=<password>' PUBLICATION pub;
   

5. Sie können die Tabelle nun auf dem Abonnenten abfragen. Sie sehen, dass sie Daten vom Herausgeber empfängt.

   SELECT * FROM basic;
   

   Sie können der Tabelle des Verlegers weitere Zeilen hinzufügen und die Änderungen auf dem Abonnenten anzeigen.

   Wenn die Daten nicht angezeigt werden können, wechseln Sie zu einem Benutzer, der Mitglied der azure_pg_admin Rolle ist, und überprüfen Sie den Tabelleninhalt.

Weitere Informationen zur logischen Replikation finden Sie in der PostgreSQL-Dokumentation.

Verwenden der logischen Replikation zwischen Datenbanken auf dem gleichen Server

Befolgen Sie spezifische Richtlinien, um die logische Replikation zwischen verschiedenen Datenbanken auf demselben Azure Database for PostgreSQL flexiblen Server einzurichten, um Implementierungseinschränkungen zu vermeiden. Derzeit können Sie nur ein Abonnement erstellen, das eine Verbindung mit demselben Datenbankcluster herstellt, wenn der Replikationsplatz nicht innerhalb desselben Befehls erstellt wird. Andernfalls hängt der CREATE SUBSCRIPTION Aufruf bei einem LibPQWalReceiverReceive Warteereignis. Dieses Verhalten ist auf eine bestehende Einschränkung innerhalb des Postgres-Moduls zurückzuführen, die in zukünftigen Versionen möglicherweise entfernt werden kann.

Führen Sie die folgenden Schritte aus, um die logische Replikation zwischen den Datenbanken "source" und "target" auf demselben Server einzurichten und diese Einschränkung zu vermeiden:

Erstellen Sie zunächst eine Tabelle basic mit einem identischen Schema in der Quell- und Zieldatenbank:

-- Run this on both source and target databases
CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);

Erstellen Sie als Nächstes in der Quelldatenbank eine Publikation für die Tabelle, und erstellen Sie separat mithilfe der pg_create_logical_replication_slot Funktion einen logischen Replikationsplatz. Dieser Ansatz trägt dazu bei, das Problem des Hängenbleibens zu verhindern, das in der Regel auftritt, wenn der Slot im selben Befehl wie die Subskription erstellt wird. Verwenden Sie das pgoutput Plug-In:

-- Run this on the source database
CREATE PUBLICATION pub FOR TABLE basic;
SELECT pg_create_logical_replication_slot('myslot', 'pgoutput');

Erstellen Sie dann in Ihrer Zieldatenbank ein Abonnement für die zuvor erstellte Publikation. Legen Sie create_slot auf false fest, um zu verhindern, dass Ihr Azure Database for PostgreSQL Flexible Server einen neuen Slot erstellt, und geben Sie den Slotnamen an, den Sie im vorherigen Schritt erstellt haben. Ersetzen Sie vor dem Ausführen des Befehls die Platzhalter in der Verbindungszeichenfolge durch Ihre tatsächlichen Datenbankanmeldeinformationen:

-- Run this on the target database
CREATE SUBSCRIPTION sub
   CONNECTION 'dbname=<source dbname> host=<server>.postgres.database.azure.com port=5432 user=<rep_user> password=<password>'
   PUBLICATION pub
   WITH (create_slot = false, slot_name='myslot');

Nachdem Sie die logische Replikation eingerichtet haben, testen Sie sie, indem Sie einen neuen Datensatz in die Tabelle in der basic Quelldatenbank einfügen und dann überprüfen, ob sie in Ihre Zieldatenbank repliziert wird:

-- Run this on the source database
INSERT INTO basic SELECT 3, 'mango';

-- Run this on the target database
TABLE basic;

Wenn alles ordnungsgemäß konfiguriert ist, wird der neue Datensatz aus der Quelldatenbank in ihrer Zieldatenbank angezeigt, und die erfolgreiche Einrichtung der logischen Replikation wird bestätigt.

pglogical-Erweiterung

Im Folgenden finden Sie ein Beispiel für die Konfiguration von pglogical auf dem Anbieter-Datenbankserver und dem Abonnenten. Weitere Informationen finden Sie in der Dokumentation zur pglogical-Erweiterung. Stellen Sie außerdem sicher, dass Sie die zuvor aufgeführten erforderlichen Aufgaben ausführen.

1. Installieren Sie die pglogical-Erweiterung in der Datenbank sowohl auf dem Anbieter als auch auf den Abonnentendatenbankservern.

   \c myDB
   CREATE EXTENSION pglogical;
   

2. Wenn der Replikationsbenutzer nicht der Administrator des Servers ist (der Benutzer, der den Server erstellt hat), gewähren Sie dem Benutzer die Mitgliedschaft in der Rolle azure_pg_admin und weisen Sie ihm die Attribute REPLICATION und LOGIN zu. Weitere Informationen finden Sie in der Dokumentation zu pglogical.

   GRANT azure_pg_admin to myUser;
   ALTER ROLE myUser REPLICATION LOGIN;
   

3. Erstellen Sie auf dem Datenbankservers des Anbieters (Quelle/Verleger) den Anbieterknoten.

   select pglogical.create_node( node_name := 'provider1',
   dsn := ' host=myProviderServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=<password>');
   

4. Erstellen Sie eine Replikatgruppe.

   select pglogical.create_replication_set('myreplicationset');
   

5. Fügen Sie der Replikatgruppe alle Tabellen in der Datenbank hinzu.

   SELECT pglogical.replication_set_add_all_tables('myreplicationset', '{public}'::text[]);
   

   Alternativ können Sie auch Tabellen aus einem bestimmten Schema (z. B. testUser) einer Standardreplikatgruppe hinzufügen.

   SELECT pglogical.replication_set_add_all_tables('default', ARRAY['testUser']);
   

6. Erstellen Sie auf dem Datenbankserver des Abonnenten einen Abonnentenknoten.

   select pglogical.create_node( node_name := 'subscriber1',
   dsn := ' host=mySubscriberServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=<password>' );
   

7. Erstellen Sie ein Abonnement, um den Synchronisierungs- und Replikationsprozess zu starten.

   select pglogical.create_subscription (
   subscription_name := 'subscription1',
   replication_sets := array['myreplicationset'],
   provider_dsn := 'host=myProviderServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=<password>');
   

8. Überprüfen Sie den Abonnementstatus.

   SELECT subscription_name, status FROM pglogical.show_subscription_status();
   

Logische Decodierung

Sie können die logische Decodierung über das Streamingprotokoll oder die SQL-Schnittstelle nutzen.

Streamingprotokoll

Die Nutzung von Änderungen mithilfe des Streamingprotokolls ist häufig vorzuziehen. Sie können Einen eigenen Consumer oder Connector erstellen oder einen Drittanbieterdienst wie Debezium verwenden.

Ein Beispiel, das das Streamingprotokoll mit pg_recvlogicalverwendet, finden Sie in der wal2json-Dokumentation: ein Beispiel zur Verwendung des Streamingprotokolls mit pg_recvlogical.

SQL-Schnittstelle

Verwenden Sie im folgenden Beispiel die SQL-Schnittstelle mit dem wal2json-Plug-In.

1. Erstellen Sie einen Slot.

   SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');
   

2. Geben Sie SQL-Befehle aus. Beispiel:

   CREATE TABLE a_table (
      id varchar(40) NOT NULL,
      item varchar(40),
      PRIMARY KEY (id)
   );
   
   INSERT INTO a_table (id, item) VALUES ('id1', 'item1');
   DELETE FROM a_table WHERE id='id1';
   

3. Verarbeiten Sie die Änderungen.

   SELECT data FROM pg_logical_slot_get_changes('test_slot', NULL, NULL, 'pretty-print', '1');
   

   Die Ausgabe sieht wie folgt aus:

   {
         "change": [
         ]
   }
   {
         "change": [
                  {
                           "kind": "insert",
                           "schema": "public",
                           "table": "a_table",
                           "columnnames": ["id", "item"],
                           "columntypes": ["character varying(40)", "character varying(40)"],
                           "columnvalues": ["id1", "item1"]
                  }
         ]
   }
   {
         "change": [
                  {
                           "kind": "delete",
                           "schema": "public",
                           "table": "a_table",
                           "oldkeys": {
                                 "keynames": ["id"],
                                 "keytypes": ["character varying(40)"],
                                 "keyvalues": ["id1"]
                           }
                  }
         ]
   }
   

4. Geben Sie den Slot frei, wenn Sie ihn nicht mehr benötigen.

   SELECT pg_drop_replication_slot('test_slot');
   

Weitere Informationen zur logischen Decodierung finden Sie in der PostgreSQL-Dokumentation: logische Decodierung.

Monitor

Sie müssen die logische Decodierung überwachen. Löschen Sie jeden nicht verwendeten Replikationsslot. Slots halten sich an Postgres WAL-Protokolle und relevante Systemkataloge, bis Änderungen gelesen werden. Wenn Ihre Abonnentin bzw. Ihr Abonnent oder Consumer ausfällt oder nicht ordnungsgemäß konfiguriert ist, werden die nicht genutzten Protokolle aufbewahrt und Ihren Speicher füllen. Außerdem erhöhen nicht verarbeitete Protokolle das Risiko von Transaktions-ID-Umläufen. Beide Situationen können dazu führen, dass der Server nicht mehr verfügbar ist. Daher müssen Sie logische Replikations-Slots kontinuierlich nutzen. Wenn ein logischer Replikationsslot nicht mehr verwendet wird, löschen Sie ihn sofort.

Die active Spalte in der pg_replication_slots Ansicht gibt an, ob ein Verbraucher mit einem Steckplatz verbunden ist.

SELECT * FROM pg_replication_slots;

Legen Sie Warnungen für die Metriken maximal verwendete Transaktions-IDs und genutzter Speicher fest, um Sie zu benachrichtigen, wenn die Werte über die normalen Schwellenwerte steigen.

Einschränkungen

• Es gelten logische Replikationseinschränkungen, wie hier dokumentiert.

• Slots und HA-Failover – In PostgreSQL 16 und früheren Versionen werden logische Replikationsplätze bei Verwendung von hochverfügbarkeitsfähigen Servern mit Azure Database for PostgreSQL nicht während Failoverereignissen beibehalten. Um logische Replikations-Slots beizubehalten und die Datenkonsistenz nach einem Failover sicherzustellen, verwenden Sie die Erweiterung PG Failover Slots und konfigurieren Sie entsprechende Einstellungen wie hot_standby_feedback = on. Weitere Informationen zum Aktivieren dieser Erweiterung finden Sie in der Dokumentation.

Unterstützung für Failover bei logischen Replikationsslots

Bei PostgreSQL 17 und höheren Versionen wird die Steckplatzsynchronisierung nativ unterstützt. Wenn Sie die richtigen PostgreSQL-Konfigurationen (sync_replication_slots, hot_standby_feedback) aktivieren, werden logische Replikationsplätze nach dem Failover automatisch beibehalten, und es ist keine Erweiterung erforderlich.

Verwandte Inhalte

• Firewallregeln in Azure-Datenbank für PostgreSQL.
• Netzwerkübersicht für Azure-Datenbank für PostgreSQL mit öffentlichem Zugriff.
• Integration virtueller Netzwerke in Azure-Datenbank für PostgreSQL.
• Verwenden von Erweiterungen.
• Hohe Verfügbarkeit in Der Azure-Datenbank für PostgreSQL.