翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# PostgreSQL エンドポイントのトラブルシューティング
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL"></a>

このセクションでは、PostgreSQL に固有のレプリケーションシナリオについて説明します。

**Topics**
+ [ソースでのトランザクション実行時間が長い](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning)
+ [ソースでの高ワークロード](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload)
+ [高いネットワークスループット](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork)
+ [Aurora PostgreSQL のスピルファイル](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill)

## ソースでのトランザクション実行時間が長い
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning"></a>

ソースデータベースで長時間実行されるトランザクション (単一トランザクションでの数千回の挿入など) がある場合、トランザクションが完了するまで DMS CDC イベントカウンターとトランザクションカウンターは増加しません。この遅延は、レイテンシーの問題につながる可能性があり、`CDCLatencyTarget` メトリクスで測定できます。

長時間実行されているトランザクションを確認するには、次のいずれかを実行します。
+ `pg_replication_slots` ビューを使用します。`restart_lsn` 値が更新されない場合、アクティブなトランザクションが長時間実行されているため、PostgreSQL はログ先行書き込み (WAL) を解放できない可能性があります。`pg_replication_slots` ビューの詳細については、「[PostgreSQL 15.4 ドキュメント](https://www.postgresql.org/docs/15/)」の「[pg\$1replication\$1slots](https://www.postgresql.org/docs/15/view-pg-replication-slots.html)」を参照してください。
+ 次のクエリを使用すると、データベース内のすべてのアクティブなクエリのリストと関連情報が返されます。

  ```
  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;
  ```

  クエリ結果の `age` フィールドには、各クエリのアクティブ期間が表示されます。長時間実行されているクエリは、これを使用して特定できます。

## ソースでの高ワークロード
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload"></a>

ソースの PostgreSQL のワークロードが高い場合は、次の点を確認してレイテンシーを低減します。
+ 1 秒あたりのトランザクション (TPS) 値が高いソースデータベースからテーブルのサブセットを移行する際に `test_decoding` プラグインを使用すると、レイテンシーが増大する可能性があります。これは、`test_decoding` プラグインがデータベースのすべての変更をレプリケーションインスタンスに送信し、DMS がタスクのテーブルマッピングに基づいてフィルタリングするためです。タスクのテーブルマッピングに含まれていないテーブルのイベントは、ソースレイテンシーを増大につながる可能性があります。
+ 次のいずれかの方法を使用して TPS スループットを確認します。
  + Aurora PostgreSQL ソースの場合、`CommitThroughput` CloudWatch メトリクスを使用します。
  + Amazon RDS またはオンプレミスで実行されている PostgreSQL の場合は、バージョン 11 以降の PSQL クライアントを使用して次のクエリを実行します (クエリ中に **enter** を押すと結果の表示を先に進めることができます)。

    ```
    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";
    ```
+ `test_decoding` プラグインを使用する際のレイテンシーを低減するには、代わりに `pglogical` プラグインの使用を検討します。`test_decoding` プラグインとは異なり、`pglogical` プラグインはソースでログ先行書き込み (WAL) の変更をフィルターして、関連する変更のみをレプリケーションインスタンスに送信します。で `pglogical`プラグインを使用する方法については AWS DMS、「」を参照してください[pgglogical プラグインの設定](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security.Pglogical)。

## 高いネットワークスループット
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork"></a>

`test_decoding` プラグインを使用すると、特に大量のトランザクションがある場合、レプリケーションのネットワーク帯域幅の使用量が増大する可能性があります。これは、`test_decoding` プラグインが変更を処理し、元のバイナリ形式よりもサイズが大きくなる判別しやすい形式に変換するためです。

パフォーマンスを向上するには、代わりにバイナリプラグインの `pglogical` プラグインの使用を検討します。`test_decoding` プラグインとは異なり、`pglogical` プラグインはバイナリ形式の出力を生成するため、圧縮されたログ先行書き込み (WAL) ストリーム変更が作成されます。

## Aurora PostgreSQL のスピルファイル
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill"></a>

PostgreSQL バージョン 13 以降では、`logical_decoding_work_mem` パラメータがデコードとストリーミングのメモリ割り当てを決定します。`logical_decoding_work_mem` パラメータの詳細については、「[PostgreSQL 13.13 Documentation](https://www.postgresql.org/docs/13/)」の「[Resource Consumption in PostgreSQL](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM)」を参照してください。

論理レプリケーションは、トランザクションがコミットされるまで、すべてのトランザクションの変更をメモリに蓄積します。すべてのトランザクションに保存されているデータの量がデータベースパラメータ `logical_decoding_work_mem` で指定された量を超える場合、DMS はトランザクションデータをディスクに書き込んで、新しいデコードデータ用にメモリを解放します。

長時間実行されるトランザクション、または多くのサブトランザクションにより、DMS の論理デコードメモリの消費が増加する可能性があります。このメモリ使用量の増加により、DMS がディスクにスピルファイルを作成し、レプリケーション中のソースのレイテンシーが高くなります。

ソースのワークロードの増加による影響を軽減するには、以下を実行します。
+ 実行時間が長いトランザクションを減らす。
+ サブトランザクションの数を減らす。
+ 単一のトランザクションでテーブル全体を削除または更新するなど、大量のログレコードを生成するオペレーションの実行を回避する。代わりに、小さなバッチでオペレーションを実行します。

次の CloudWatch メトリクスを使用して、ソースのワークロードをモニタリングできます。
+ `TransactionLogsDiskUsage`: 論理 WAL によって現在占有されているバイト数。この値は、論理レプリケーションスロットが新しい書き込みのペースに遅れを取る場合、または長時間実行されているトランザクションが古いファイルのガベージコレクションを妨げている場合、一定間隔で増加します。
+ `ReplicationSlotDiskUsage`: 論理レプリケーションスロットが現在使用しているディスク容量。

`logical_decoding_work_mem` パラメータをチューニングすることで、ソースのレイテンシーを軽減することができます。このパラメータのデフォルト値は 64 MB です。このパラメータは、各論理ストリーミングレプリケーションの接続で使用されるメモリの量を制限します。DMS がディスクに書き込むデコードされた変更の量を減らすために、`logical_decoding_work_mem` 値を `work_mem` 値より大幅に大きく設定することをお勧めします。

特に重い移行アクティビティやレイテンシーの場合、定期的にスピルファイルをチェックすることをお勧めします。DMS が大量のスピルファイルを作成している場合、論理デコードが効率的に動作していないことを意味し、レイテンシーが増加する可能性があります。これを軽減するには、`logical_decoding_work_mem` パラメータ値を大きくします。

`aurora_stat_file` 関数を使用して、現在のトランザクションオーバーフローを確認できます。詳細については、「*Amazon Relational Database Service デベロッパーガイド*」の「[論理デコード用のワーキングメモリの調整](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem)」を参照してください。