Fehlerbehebung für SQL Postgre-Endgeräte - AWS Database Migration Service
Lang laufende Transaktion in der QuelleHoher Workload in der QuelleHohen NetzwerkdurchsatzDateien in Aurora Postgre ausgeben SQL

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.

Fehlerbehebung für SQL Postgre-Endgeräte

Dieser Abschnitt enthält Replikationsszenarien, die für SQL Postgre spezifisch sind.

Lang laufende Transaktion in der Quelle

Wenn in der Quelldatenbank Transaktionen mit langer Laufzeit vorhanden sind, z. B. einige Tausend Einfügungen in einer einzelnen Transaktion, steigen die DMS CDC Ereignis- und Transaktionszähler erst, 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 restart_lsn Wert nicht aktualisiert wird, ist es wahrscheinlich, dass Postgre aufgrund von lang andauernden aktiven Transaktionen nicht in der Lage SQL ist, Write-Ahead-Logs (WALs) zu veröffentlichen. Informationen zur pg_replication_slots Ansicht finden Sie unter pg_replication_slots in der Postgre 15.4-Dokumentation. SQL

  • 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 Ihr Quell-Postgre eine hohe Arbeitslast SQL hat, überprüfen Sie Folgendes, um die Latenz zu reduzieren:

  • Wenn Sie das test_decoding Plug-In verwenden, während Sie eine Teilmenge von Tabellen aus der Quelldatenbank mit einem hohen Wert für Transaktionen pro Sekunde () TPS migrieren, kann es zu einer hohen Latenz kommen. Das liegt daran, dass das test_decoding Plugin alle Datenbankänderungen an die Replikationsinstanz sendet, die DMS dann auf der Grundlage 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 mit einer der folgenden Methoden.

    • Verwenden Sie für Aurora SQL Postgre-Quellen die CommitThroughput CloudWatch Metrik.

    • Verwenden Sie für Postgre, das auf Amazon RDS oder lokal SQL ausgeführt wird, die folgende Abfrage mit einer PSQL Client-Version 11 oder höher (Drücken Sie enter während der Abfrage, 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 test_decoding Plug-in filtert das pglogical Plug-In die Protokolländerungen (WAL) im Voraus an der Quelle und sendet nur relevante Änderungen an die Replikationsinstanz. Hinweise zur Verwendung des pglogical Plug-ins mit AWS DMS finden Sie unterKonfigurieren 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 test_decoding Plug-In generiert das pglogical Plug-In eine Ausgabe im Binärformat, was zu Änderungen des komprimierten Write-Ahead-Log-Streams (WAL) führt.

Dateien in Aurora Postgre ausgeben SQL

In SQL Postgre-Version 13 und höher bestimmt der logical_decoding_work_mem Parameter die Speicherzuweisung für Decodierung und Streaming. Weitere Informationen zum logical_decoding_work_mem Parameter finden Sie unter Ressourcenverbrauch in Postgre SQL in der Dokumentation zu Postgre 13.13. SQL

Bei der logischen Replikation werden Änderungen für alle Transaktionen im Speicher gesammelt, bis diese Transaktionen festgeschrieben werden. Wenn die in allen Transaktionen gespeicherte Datenmenge die durch den Datenbankparameter angegebene Menge überschreitetlogical_decoding_work_mem, werden die Transaktionsdaten auf die DMS Festplatte übertragen, um Speicherplatz für neue Dekodierungsdaten freizugeben.

Lang andauernde Transaktionen oder viele Untertransaktionen können dazu führen, dass mehr Speicher für die logische DMS Dekodierung verbraucht wird. Diese erhöhte Speicherauslastung führt dazu, dass Spill-Dateien auf der Festplatte DMS entstehen, was zu einer hohen Quellenlatenz während der Replikation führt.

Gehen Sie wie folgt vor, um die Auswirkungen einer Erhöhung der Quell-Workload zu verringern:

  • Reduzieren Sie lang andauernde Transaktionen.

  • Reduzieren Sie die Anzahl der Untertransaktionen.

  • Vermeiden Sie es, Operationen auszuführen, 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 durch.

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

  • TransactionLogsDiskUsage: Die Anzahl der Byte, die derzeit vom logischen System belegt sindWAL. Dieser Wert steigt monoton an, wenn die logischen Replikationssteckplätze nicht in der Lage sind, mit der Geschwindigkeit neuer Schreibvorgänge Schritt zu halten, oder wenn lange laufende Transaktionen die Garbage-Collection älterer Dateien verhindern.

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

Sie können die Latenz der Quelle 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. Es wird empfohlen, den logical_decoding_work_mem Wert deutlich höher als den work_mem Wert festzulegen, um die Anzahl der dekodierten Änderungen zu reduzieren, die auf die Festplatte DMS geschrieben werden.

Es wird empfohlen, Dateien regelmäßig auf überladene Dateien zu überprüfen, insbesondere in Zeiten starker Migrationsaktivitäten oder Latenz. Wenn eine große Anzahl von Spill-Dateien erstellt DMS wird, bedeutet dies, dass die logische Dekodierung nicht effizient funktioniert, was die Latenz erhöhen kann. Um dies zu verringern, 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 Developer Guide.