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
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL"></a>

Dieser Abschnitt enthält spezifische Replikationsszenarien für PostgreSQL.

**Topics**
+ [Long-running Transaktion an der Quelle](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning)
+ [Hoher Workload in der Quelle](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload)
+ [Hohen Netzwerkdurchsatz](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork)
+ [Dateien in Aurora PostgreSQL verschütten](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill)

## Long-running Transaktion an der Quelle
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning"></a>

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](https://www.postgresql.org/docs/15/view-pg-replication-slots.html) in der [Dokumentation zu PostgreSQL 15.4](https://www.postgresql.org/docs/15/).
+ 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
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload"></a>

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](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security.Pglogical)

## Hohen Netzwerkdurchsatz
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork"></a>

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
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill"></a>

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 ](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM) in der PostgreSQL 13.13-Dokumentation. [https://www.postgresql.org/docs/13/](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 überschreitet`logical_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 ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem) im * Amazon Relational Database Service Developer Guide. *