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.
Fehlersuche bei PostgreSQL-Endpunkten
Dieser Abschnitt enthält spezifische Replikationsszenarien für PostgreSQL.
Themen
Lang laufende Transaktion in der Quelle
Wenn in der Quelldatenbank lang laufende Transaktionen vorhanden sind, z. B. einige Tausend Einfügungen in einer einzelnen Transaktion, steigen die DMS-CDC-Ereignis- und Transaktionszähler erst an, wenn die Transaktion abgeschlossen ist. Diese Verzögerung kann Latenzprobleme verursachen, die Sie anhand der Metrik CDCLatencyTarget
messen können.
Führen Sie einen der folgenden Schritte aus, um lang laufende Transaktionen zu überprüfen:
Verwenden Sie die Ansicht
pg_replication_slots
. Wenn der Wertrestart_lsn
nicht aktualisiert wird, kann PostgreSQL wahrscheinlich aufgrund von lang laufenden aktiven Transaktionen keine Write-Ahead-Protokolle (WALs) veröffentlichen. Informationen zur Ansichtpg_replication_slots
finden Sie unter pg_replication_slotsin der Dokumentation zu PostgreSQL 15.4 . Verwenden Sie die folgende Abfrage, um eine Liste aller aktiven Abfragen in der Datenbank zusammen mit den zugehörigen Informationen zurückzugeben:
SELECT pid, age(clock_timestamp(), query_start), usename, query FROM pg_stat_activity WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' ORDER BY query_start desc;
Das Feld
age
in den Abfrageergebnissen zeigt die aktive Dauer der einzelnen Abfragen an, anhand derer Sie lang laufende Abfragen identifizieren können.
Hoher Workload in der Quelle
Wenn Ihre PostgreSQL-Quelle einen hohen Workload aufweist, überprüfen Sie Folgendes, um die Latenz zu reduzieren:
-
Wenn Sie das Plug-in
test_decoding
während der Migration einer Teilmenge von Tabellen aus der Quelldatenbank mit einem hohen TPS-Wert (Transaktionen pro Sekunde) verwenden, kann es zu einer hohen Latenz kommen. Dies liegt daran, dass das Plug-intest_decoding
alle Datenbankänderungen an die Replikations-Instance sendet, die DMS dann basierend auf der Tabellenzuordnung der Aufgabe filtert. Ereignisse für Tabellen, die nicht Teil der Tabellenzuordnung der Aufgabe sind, können die Quelllatenz erhöhen. -
Überprüfen Sie den TPS-Durchsatz anhand einer der folgenden Methoden:
Verwenden Sie für Aurora-PostgreSQL-Quellen die -
CommitThroughput
CloudWatch Metrik.Verwenden Sie für PostgreSQL, das in Amazon RDS oder On-Premises ausgeführt wird, die folgende Abfrage mit einem PSQL-Client der Version 11 oder höher (drücken Sie während der Abfrage
enter
, um die Ergebnisse weiterzuleiten):SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset select pg_sleep(60); SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";
Um die Latenz bei der Verwendung des Plug-ins
test_decoding
zu reduzieren, sollten Sie stattdessen das Plug-inpglogical
verwenden. Im Gegensatz zum Plug-intest_decoding
filtert das Plug-inpglogical
Änderungen an Write-Ahead-Protokollen (WALs) an der Quelle und sendet nur relevante Änderungen an die Replikations-Instance. Informationen zur Verwendung des Plug-inspglogical
mit AWS DMS finden Sie unter Konfigurieren des Plug-ins pglogical.
Hohen Netzwerkdurchsatz
Bei Ihrer Replikation wird möglicherweise eine hohe Netzwerkbandbreite beansprucht, wenn Sie das Plug-in test_decoding
verwenden, insbesondere bei Transaktionen mit hohem Volumen. Dies liegt daran, dass das Plug-in test_decoding
Änderungen verarbeitet und in ein für Menschen lesbares Format umwandelt, das größer als das ursprüngliche Binärformat ist.
Zum Verbessern der Leistung sollten Sie stattdessen das Plug-in pglogical
verwenden, bei dem es sich um ein binäres Plug-in handelt. Im Gegensatz zum Plug-in test_decoding
generiert das Plug-in pglogical
eine Ausgabe im Binärformat, was zu komprimierten Änderungen des Write-Ahead-Protokoll (WAL)-Streams führt.
Überlaufdateien in Aurora PostgreSQL
In PostgreSQL Version 13 und höher bestimmt der logical_decoding_work_mem
Parameter die Speicherzuweisung für die Dekodierung und das Streaming. Weitere Informationen zum logical_decoding_work_mem
Parameter finden Sie unter Ressourcennutzung in PostgreSQL
Die logische Replikation akkumuliert Änderungen für alle Transaktionen im Speicher, bis diese Transaktionen festgeschrieben werden. Wenn die Menge der in allen Transaktionen gespeicherten Daten die durch den Datenbankparameter angegebene Menge überschreitetlogical_decoding_work_mem
, übergibt DMS die Transaktionsdaten auf die Festplatte, um Speicher für neue Dekodierungsdaten freizugeben.
Lang andauernde Transaktionen oder viele Untertransaktionen können dazu führen, dass DMS mehr logischen Dekodierungsspeicher verbraucht. Dieser erhöhte Speicherverbrauch führt dazu, dass DMS Spill-Dateien auf der Festplatte erstellt, was zu einer hohen Quelllatenz während der Replikation führt.
Gehen Sie wie folgt vor, um die Auswirkungen einer Erhöhung der Quell-Workload zu reduzieren:
Reduzieren Sie lang andauernde Transaktionen.
Reduzieren Sie die Anzahl der Teiltransaktionen.
Vermeiden Sie das Ausführen von Operationen, die einen großen Burst von Protokolldatensätzen erzeugen, z. B. das Löschen oder Aktualisieren einer gesamten Tabelle in einer einzigen Transaktion. Führen Sie stattdessen Operationen in kleineren Stapeln aus.
Sie können die folgenden CloudWatch Metriken verwenden, um den Workload auf der Quelle zu überwachen:
TransactionLogsDiskUsage
: Die Anzahl der Bytes, die derzeit vom logischen WAL belegt werden. Dieser Wert steigt monoton, wenn logische Replikationsslots nicht mit dem Tempo neuer Schreibvorgänge Schritt halten können oder wenn lang andauernde Transaktionen die Garbage Collection älterer Dateien verhindern.ReplicationSlotDiskUsage
: Der Speicherplatz, den die logischen Replikations-Slots derzeit verwenden.
Sie können die Quelllatenz reduzieren, indem Sie den logical_decoding_work_mem
Parameter optimieren. Der Standardwert für diesen Parameter ist 64 MB. Dieser Parameter begrenzt die Speichermenge, die von jeder logischen Streaming-Replikationsverbindung verwendet wird. Wir empfehlen, den logical_decoding_work_mem
Wert deutlich höher als den work_mem
Wert festzulegen, um die Menge der dekodierten Änderungen zu reduzieren, die DMS auf die Festplatte schreibt.
Wir empfehlen Ihnen, regelmäßig nach Spill-Dateien zu suchen, insbesondere in Zeiten hoher Migrationsaktivität oder Latenz. Wenn DMS eine erhebliche Anzahl von Spill-Dateien erstellt, bedeutet dies, dass die logische Dekodierung nicht effizient funktioniert, was die Latenz erhöhen kann. Um dies zu minimieren, erhöhen Sie den logical_decoding_work_mem
Parameterwert.
Sie können den aktuellen Transaktionsüberlauf mit der aurora_stat_file
Funktion überprüfen. Weitere Informationen finden Sie unter Anpassen des Arbeitsspeichers für die logische Dekodierung im Amazon Relational Database Service-Entwicklerhandbuch.