Verwenden der logischen PostgreSQL-Replikation mit Multi-AZ-DB-Clustern - Amazon Relational Database Service

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden der logischen PostgreSQL-Replikation mit Multi-AZ-DB-Clustern

Durch die Verwendung der logischen PostgreSQL-Replikation mit Ihrem Multi-AZ-DB-Cluster können Sie einzelne Tabellen anstelle der gesamten Datenbank-Instance replizieren und synchronisieren. Für die logische Replikation wird ein Veröffentlichungs- und Abonnementmodell verwendet, um Änderungen aus einer Quelle an einen oder mehrere Empfänger zu replizieren. Dazu werden Änderungsdatensätze aus dem Write-Ahead-Protokoll (WAL) von PostgreSQL verwendet. Weitere Informationen finden Sie unter Durchführen einer logischen Replikation für Amazon RDS for Postgre SQL.

Wenn Sie einen neuen Slot für die logische Replikation auf der Writer-DB-Instance eines Multi-AZ-DB-Clusters erstellen, wird der Slot asynchron in jede Reader-DB-Instance im Cluster kopiert. Die Slots auf den Reader-DB-Instances werden kontinuierlich mit den Slots auf der Writer-DB-Instance synchronisiert.

Die logische Replikation wird für Multi-AZ-DB-Cluster unterstützt, auf denen RDS für PostgreSQL Version 14.8-R2 und höher sowie 15.3-R2 und höher ausgeführt wird.

Anmerkung

Zusätzlich zu der nativen logischen Replikationsfunktion von PostgreSQL unterstützen Multi-AZ-DB-Cluster, auf denen RDS für PostgreSQL ausgeführt wird, auch die pglogical-Erweiterung.

Weitere Informationen über die logische Replikation in PostgreSQL finden Sie unter Logische Replikation in der PostgreSQL-Dokumentation.

Voraussetzungen

Um die logische Replikation von PostgreSQL für Multi-AZ-DB-Cluster zu konfigurieren, müssen Sie die folgenden Voraussetzungen erfüllen.

Einrichten der logischen Replikation

Um eine logische Replikation für einen Multi-AZ-DB-Cluster einzurichten, aktivieren Sie bestimmte Parameter innerhalb der zugehörigen DB-Cluster-Parametergruppe und erstellen dann Slots für die logische Replikation.

Anmerkung

Ab PostgreSQL Version 16 können Sie Reader-DB-Instances des Multi-AZ-DB-Clusters für die logische Replikation verwenden.

So richten Sie eine logische Replikation für einen Multi-AZ-DB-Cluster von RDS für PostgreSQL ein
  1. Öffnen Sie die benutzerdefinierte DB-Cluster-Parametergruppe, die Ihrem Multi-AZ-DB-Cluster von RDS für PostgreSQL zugeordnet ist.

  2. Suchen Sie im Suchfeld Parameter nach dem statischen Parameter rds.logical_replication und legen Sie als Wert für den Parameter 1 fest. Diese Parameteränderung kann zu einer verstärkten WAL-Generierung führen. Aktivieren Sie sie daher nur, wenn Sie logische Slots verwenden.

  3. Konfigurieren Sie im Rahmen dieser Änderung die folgenden DB-Cluster-Parameter.

    • max_wal_senders

    • max_replication_slots

    • max_connections

    Abhängig von Ihrer erwarteten Auslastung müssen Sie möglicherweise auch die Werte der folgenden Parameter ändern. In vielen Fällen sind die Standardwerte jedoch ausreichend.

    • max_logical_replication_workers

    • max_sync_workers_per_subscription

  4. Starten Sie den Multi-AZ-DB-Cluster neu, damit die Parameterwerte wirksam werden. Anweisungen finden Sie unter Neustart von Multi-AZ-DB-Clustern und Reader-DB-Instances.

  5. Erstellen Sie einen Slot für die logische Replikation auf der Writer-DB-Instance des Multi-AZ-DB-Clusters, wie unter Arbeiten mit logischen Replikations-Slots beschrieben. Für diesen Prozess ist es erforderlich, dass Sie ein Decodier-Plugin angeben. Derzeit unterstützt RDS für PostgreSQL die test_decoding-, wal2json- und pgoutput-Plugins, die mit PostgreSQL geliefert werden.

    Der Slot wird asynchron in jede Reader-DB-Instance im Cluster kopiert.

  6. Überprüfen Sie den Status des Slots auf allen Reader-DB-Instances des Multi-AZ-DB-Clusters. Überprüfen Sie hierfür die Ansicht pg_replication_slots auf allen Reader-DB-Instances und stellen Sie sicher, dass der confirmed_flush_lsn-Status voranschreitet, während die Anwendung aktiv logische Änderungen verarbeitet.

    Die folgenden Befehle veranschaulichen, wie der Replikationsstatus auf den Reader-DB-Instances überprüft werden kann.

    % psql -h test-postgres-instance-2.abcdefabcdef.us-west-2.rds.amazonaws.com postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn --------------+-----------+--------------------- logical_slot | logical | 32/D0001700 (1 row) postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn --------------+-----------+--------------------- logical_slot | logical | 32/D8003628 (1 row) % psql -h test-postgres-instance-3.abcdefabcdef.us-west-2.rds.amazonaws.com postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn --------------+-----------+--------------------- logical_slot | logical | 32/D0001700 (1 row) postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn --------------+-----------+--------------------- logical_slot | logical | 32/D8003628 (1 row)

Beenden Sie nach Abschluss Ihrer Replikationsaufgaben den Replikationsprozess, löschen Sie die Replikationsslots und deaktivieren Sie die logische Replikation. Um die logische Replikation zu deaktivieren, ändern Sie Ihre DB-Cluster-Parametergruppe und setzen Sie den Wert von rds.logical_replication auf 0 zurück. Starten Sie den Cluster neu, damit die Parameteränderung in Kraft tritt.

Einschränkungen und Empfehlungen

Die folgenden Einschränkungen und Empfehlungen gelten für die Verwendung der logischen Replikation mit Multi-AZ-DB-Clustern, auf denen PostgreSQL Version 16 ausgeführt wird:

  • Sie können nur Writer-DB-Instances verwenden, um logische Replikationsslots zu erstellen oder zu löschen. Beispielsweise muss der CREATE SUBSCRIPTION Befehl den Cluster-Writer-Endpunkt in der Host-Verbindungszeichenfolge verwenden.

  • Sie müssen den Cluster-Writer-Endpunkt bei jeder Tabellensynchronisation oder Resynchronisierung verwenden. Sie können beispielsweise die folgenden Befehle verwenden, um eine neu hinzugefügte Tabelle erneut zu synchronisieren:

    Postgres=>ALTER SUBSCRIPTION subscription-name CONNECTION host=writer-endpoint Postgres=>ALTER SUBSCRIPTION subscription-name REFRESH PUBLICATION
  • Sie müssen warten, bis die Tabellensynchronisierung abgeschlossen ist, bevor Sie die Reader-DB-Instances für die logische Replikation verwenden können. Sie können die pg_subscription_rel Katalogtabelle verwenden, um die Tabellensynchronisation zu überwachen. Die Tabellensynchronisierung ist abgeschlossen, wenn die srsubstate Spalte auf ready (r) gesetzt ist.

  • Es wird empfohlen, Instanzendpunkte für die logische Replikationsverbindung zu verwenden, sobald die erste Tabellensynchronisierung abgeschlossen ist. Der folgende Befehl reduziert die Belastung der Writer-DB-Instance, indem die Replikation auf eine der Reader-DB-Instances verlagert wird:

    Postgres=>ALTER SUBSCRITPION subscription-name CONNECTION host=reader-instance-endpoint

    Sie können denselben Slot nicht auf mehr als einer DB-Instance gleichzeitig verwenden. Wenn zwei oder mehr Anwendungen logische Änderungen von verschiedenen DB-Instances im Cluster replizieren, können einige Änderungen aufgrund eines Cluster-Failovers oder eines Netzwerkproblems verloren gehen. In diesen Situationen können Sie Instanzendpunkte für die logische Replikation in der Host-Verbindungszeichenfolge verwenden. Die andere Anwendung, die dieselbe Konfiguration verwendet, zeigt die folgende Fehlermeldung an:

    replication slot slot_name is already active for PID x providing immediate feedback.
  • Wenn Sie die pglogical Erweiterung verwenden, können Sie nur den Cluster-Writer-Endpunkt verwenden. Die Erweiterung hat bekannte Einschränkungen, die dazu führen können, dass bei der Tabellensynchronisierung ungenutzte logische Replikationsslots entstehen. Veraltete Replikationssteckplätze reservieren WAL-Dateien (Write-Ahead Log) und können zu Speicherplatzproblemen führen.