Wie behebe ich logische Replikationsprobleme für einen Quell-DB-Cluster von Aurora PostgreSQL-Compatible?

Lösung

Konfigurieren der Replikationsparameter

Bevor du Probleme mit der logischen Replikation behebst, konfiguriere die folgenden Parameter für die DB-Cluster-Parametergruppe:

• Setze den Wert rds.logical_replication auf 1, um die logische Replikation auf dem DB-Cluster zu aktivieren.
• Lege einen Wert für max_replication_slots fest, der genügend Slots für die erwartete Abonnementanzahl und zusätzliche Tabellensynchronisierungsprozesse umfasst.
• Setze max_wal_senders auf einen Wert, der das max_replication_slots-Kontingent und die aktuellen physischen Replikate unterstützt.
• Setze max_logical_replication_workers auf einen Wert, der die Abonnementanzahl und die Anzahl zusätzlicher Worker, die das Replikationssystem für die Tabellensynchronisierung benötigt, unterstützt.
• Setze max_worker_processes auf einen Wert, der mindestens um eins höher ist als der Wert max_logical_replication_workers. Wenn max_logical_replication_workers beispielsweise 25 ist, setze max_worker_processes auf 26.
• Wenn das Kopieren der Daten langsam ist, erhöhe den Wert max_sync_workers_per_subscription, um die Anzahl der Synchronisierungs-Worker zu steuern, die die Einrichtung des Abonnements und das Hinzufügen neuer Tabellen verarbeiten.

Wichtig: Um die vorherigen Änderungen zu übernehmen, musst du den DB-Cluster von Aurora PostgreSQL-Compatible neu starten.

Überprüfen der Veröffentlichungs- und Abonnementkonfiguration

Nachdem du die logischen Replikationsparameter konfiguriert hast, stelle sicher, dass du die Veröffentlichungen und Abonnements richtig konfiguriert hast. Stelle sicher, dass die Veröffentlichung alle vorgesehenen Tabellen enthält, dass die Abonnementparameter korrekt sind und der/die Replikationsbenutzer:in über die entsprechenden Berechtigungen verfügt.

Stelle eine Verbindung zur Quelldatenbank her und führe dann die folgenden Befehle aus.

Führe die folgenden Befehle aus, um die Veröffentlichungskonfiguration zu überprüfen:

SELECT * FROM pg_publication;
SELECT * FROM pg_publication_tables;

Führe die folgenden Befehle aus, um die Abonnementkonfiguration zu überprüfen:

SELECT * FROM pg_subscription;
SELECT * FROM pg_subscription_rel;

Sich vergewissern, dass die Replikationsslots aktiv sind

Stelle eine Verbindung zur Quelldatenbank her und führe dann den folgenden Befehl aus:

SELECT slot_name, plugin, slot_type, active, restart_lsn,
       confirmed_flush_lsn, pg_current_wal_lsn(),
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots;

Wenn Slots inaktiv sind oder eine übermäßige Verzögerung aufweisen, überprüfe die Replikations-Worker, um das Problem zu beheben.

Sich vergewissern, dass die Replikations-Worker aktiv sind 

Stelle eine Verbindung zur Zieldatenbank her und führe dann den folgenden Befehl aus:

SELECT pid, state, query, wait_event, backend_type
FROM pg_stat_activity
WHERE backend_type LIKE 'logical replication%';

Wenn keine Replikations-Worker vorhanden sind, starte das Abonnement neu.

Führe den folgenden Befehl aus, um das Abonnement zu deaktivieren:

ALTER SUBSCRIPTION subscription_name DISABLE;

Führe den folgenden Befehl aus, um das Abonnement zu aktivieren:

ALTER SUBSCRIPTION subscription_name ENABLE;

Wenn nach dem Neustart des Abonnements immer noch keine Replikations-Worker vorhanden sind, überprüfe die PostgreSQL-Fehlerprotokolle auf Fehlermeldungen.

Überwachen des Fortschritts und der Verzögerung der Replikation

Bei der Replikation kann es aufgrund des hohen Transaktionsvolumens und der großen Transaktionen in der Veröffentlichung zu Verzögerungen kommen. Oder es gibt möglicherweise Einschränkungen für die Veröffentlichung oder das Abonnement.

Überwache den Fortschritt der Replikation einige Intervalle lang, um festzustellen, ob die Replikation angehalten wurde oder langsam ist. 

Stelle eine Verbindung zum DB-Cluster her und führe dann die folgenden Befehle aus.

Führe den folgenden Befehl aus, um den Replikationsfortschritt für die Veröffentlichung zu überprüfen:

SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag,
       active
FROM pg_replication_slots
WHERE slot_type = 'logical';

Führe den folgenden Befehl aus, um den Replikationsfortschritt für das Abonnement zu überprüfen:

SELECT subname, pid, received_lsn, latest_end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, received_lsn)) AS lag
FROM pg_stat_subscription;

Überwache den Write-Through-Cache, um die Replikationsverzögerung zu minimieren. Wenn die Cachegröße für die Workloads nicht ausreicht, kannst du den Wert rds.logical_wal_cache ändern. Weitere Informationen findest du unter Erziele eine bis zu 17-mal geringere Replikationsverzögerung mit dem neuen Write-Through-Cache für Aurora PostgreSQL.

Überwachen der Ressourcenbeschränkungen

Um Ressourcenbeschränkungen für Publisher und Subscriber zu beheben, aktiviere Enhanced Monitoring und überwache CPUUtilization, FreeableMemory, SwapUsage und NetworkThroughput. Richte Amazon-CloudWatch-Alarme ein, um benachrichtigt zu werden, wenn Replikationsprobleme auftreten.

Weitere Informationen findest du unter Wie identifiziere und behebe ich Leistungsprobleme und Abfragen mit langsamer Ausführung in meiner DB-Instance von Amazon RDS für PostgreSQL oder Aurora PostgreSQL-Compatible?

Identifizieren von Schemakonflikten und Beheben von Dateninkonsistenzen

Stelle eine Verbindung zur Quell- und Zieldatenbank her. Vergewissere dich dann, dass die replizierten Tabellen Spalten enthalten und die Datentypen kompatibel sind. Stelle außerdem sicher, dass die Primärschlüssel und eindeutigen Beschränkungen konsistent sind. 

Führe den folgenden Befehl aus, um das Abonnement zu aktivieren:

ALTER SUBSCRIPTION subscription_name ENABLE;

Führe den folgenden Befehl für beide Datenbanken aus, um Tabellendefinitionen zu vergleichen:

SELECT column_name, data_type, character_maximum_length
FROM information_schema.columns
WHERE table_name = 'your_table_name'
ORDER BY ordinal_position;

Hinweis: Ersetze your_table_name durch deinen Tabellennamen.

Konflikte lösen

Die native logische PostgreSQL-Replikation kann keine Datenkonflikte von mehreren Publishern oder replizierte Änderungen erkennen, die mit Daten in Konflikt stehen, die du lokal geändert hast. Wenn es eine aktuelle Zeile mit demselben Schlüssel gibt, wendet Aurora das Update an und das Einfügen schlägt fehl. 

Um herauszufinden, was den Konflikt verursacht hat, überprüfe die PostgreSQL-Protokolle. 

Das folgende Beispielprotokoll zeigt, dass die Replikation fehlgeschlagen ist, weil versucht wurde, einen Datensatz mit einer Objekt-ID einzufügen, die bereits in der Zieldatenbank vorhanden ist:

ERROR: 23505: duplicate key value violates unique constraint "asset_pkey"
DETAIL: Key (asset_id)=(7) already exists.
CONTEXT: processing remote data for replication origin "pg_32796" during message type "INSERT" for replication target relation "public.asset" in transaction 315434, finished at 0/6A12458

Der Replikationsursprung ist pg_32796 und endet bei Logical Sequence Number (LSN, Logische Sequenznummer) 0/6A12458.

Um die Daten manuell zu korrigieren, kannst du die Replikation bei Konflikten beenden oder das Abonnement mit der Option disable_on_error konfigurieren.

Du kannst auch die Daten an Quelle und Ziel überprüfen, um festzustellen, ob du die LSN, die den Konflikt verursacht hat, überspringen kannst. Verwende dann die Funktion pg_replication_origin_advance(), um die LSN zu überspringen, die den Konflikt verursacht hat. Weitere Informationen findest du unter pg_replication_origin_advance (node_name text, lsn pg_lsn) auf der PostgreSQL-Website.

Hinweis: Versionen 15 und höher unterstützen die Funktion pg_replication_origin_advance().

Gehe wie folgt vor, um die LSN zu überspringen:

1. Führe den folgenden SQL-Befehl aus, um das Abonnement vorübergehend zu deaktivieren:

   ALTER SUBSCRIPTION subscription_name DISABLE;

   Hinweis: Wenn du das Abonnement mit der Option disable_on_error konfiguriert hast, wird das Abonnement nach einem Fehler automatisch deaktiviert.

2. Verwende die folgende Funktion pg_replication_origin_advance(), um den Ursprung an Finish_LSN+1 weiterzuleiten:

   SELECT pg_replication_origin_advance('node_name','Finish_LSN+1'::pg_lsn);

   Hinweis: Ersetze node_name durch den Namen deines Knotens.

3. Führe den folgenden Befehl aus, um das Abonnement zu aktivieren:

   ALTER SUBSCRIPTION subscription-name ENABLE;

   Hinweis: Ersetze subscription-name durch deinen Abonnementnamen.

Um mehrere Dateninkonsistenzen zu beheben, musst du möglicherweise die Zieltabelle bereinigen und die Veröffentlichung und das Abonnement neu konfigurieren.

Ähnliche Informationen

Replikation mit Amazon Aurora PostgreSQL

PostgreSQL Logical Replication (Logische PostgreSQL-Replikation) auf der PostgreSQL-Website

Logische Replikation für den Aurora-PostgreSQL-DB-Cluster einrichten

Überwachen von Amazon-Aurora-Metriken mit Amazon CloudWatch