Fehlersuche bei PostgreSQL-Endpunkten - AWS Database Migration Service
Lang laufende Transaktion in der QuelleHoher Workload in der QuelleHohen NetzwerkdurchsatzÜberlaufdateien in Aurora PostgreSQL

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.

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 Wert restart_lsn nicht aktualisiert wird, kann PostgreSQL wahrscheinlich aufgrund von lang laufenden aktiven Transaktionen keine Write-Ahead-Protokolle (WALs) veröffentlichen. Informationen zur Ansicht pg_replication_slots finden Sie unter pg_replication_slots in 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-in test_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-in pglogical verwenden. Im Gegensatz zum Plug-in test_decoding filtert das Plug-in pglogical Änderungen an Write-Ahead-Protokollen (WALs) an der Quelle und sendet nur relevante Änderungen an die Replikations-Instance. Informationen zur Verwendung des Plug-ins pglogical 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 in der PostgreSQL 13.13-Dokumentation.

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.