View a markdown version of this page

Fehlersuche bei PostgreSQL-Endpunkten - AWS Datenbankmigrationsdienst
Long-running Transaktion an der QuelleHoher Workload in der QuelleHohen NetzwerkdurchsatzDateien in Aurora PostgreSQL verschütten

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.

Long-running Transaktion an 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, state, query 
FROM pg_stat_activity WHERE state != '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. Hinweise zur Verwendung des pglogical Plugins mit finden Sie AWS DMS 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.

Dateien in Aurora PostgreSQL verschütten

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 zu dem logical_decoding_work_mem Parameter finden Sie unter Ressourcenverbrauch in PostgreSQL in der PostgreSQL 13.13-Dokumentation. https://www.postgresql.org/docs/13/

Bei der logischen Replikation werden Änderungen für alle Transaktionen im Speicher akkumuliert, bis diese Transaktionen festgeschrieben werden. Wenn die für alle Transaktionen gespeicherte Datenmenge die im Datenbankparameter angegebene Menge überschreitetlogical_decoding_work_mem, überträgt DMS die Transaktionsdaten auf die Festplatte, um Speicherplatz für neue Decodierungsdaten freizugeben.

Langandauernde Transaktionen oder viele Untertransaktionen können dazu führen, dass DMS mehr logischen Decodierungsspeicher verbraucht. Diese erhöhte Speicherauslastung führt dazu, dass DMS Überlaufdateien 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 des Quell-Workloads zu verringern:

  • Reduzieren Sie lang andauernde Transaktionen.

  • Reduzieren Sie die Anzahl der Untertransaktionen.

  • Vermeiden Sie die Ausführung von Vorgängen, die eine große Anzahl von Protokolldatensätzen generieren, wie z. B. das Löschen oder Aktualisieren einer ganzen Tabelle in einer einzigen Transaktion. Führen Sie Operationen stattdessen in kleineren Batches aus.

Sie können die folgenden CloudWatch Metriken verwenden, um die Arbeitslast an der Quelle zu überwachen:

  • TransactionLogsDiskUsage: Die Anzahl der Byte, die derzeit von der logischen WAL belegt sind. Dieser Wert steigt monoton an, wenn logische Replikationssteckplätze nicht in der Lage sind, mit dem Tempo neuer Schreibvorgänge Schritt zu halten, oder wenn langandauernde Transaktionen die Garbage-Collection älterer Dateien verhindern.

  • ReplicationSlotDiskUsage: Die Menge an Festplattenspeicher, die die logischen Replikationsslots derzeit belegen.

Sie können die Quelllatenz reduzieren, indem Sie den logical_decoding_work_mem Parameter anpassen. 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 einzustellen, um die Menge der dekodierten Änderungen zu reduzieren, die DMS auf die Festplatte schreibt.

Wir empfehlen, dass Sie regelmäßig nach Spilldateien suchen, insbesondere in Zeiten hoher Migrationsaktivität oder Latenz. Wenn DMS eine erhebliche Anzahl von Spillfiles erstellt, bedeutet dies, dass die logische Dekodierung nicht effizient funktioniert, was die Latenz erhöhen kann. Erhöhen Sie den Parameterwert, um dem entgegenzuwirken. logical_decoding_work_mem

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 Developer Guide.