PostgreSQL エンドポイントのトラブルシューティング

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

ソースでのトランザクション実行時間が長い

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

長時間実行されているトランザクションを確認するには、次のいずれかを実行します。

• pg_replication_slots ビューを使用します。restart_lsn 値が更新されない場合、アクティブなトランザクションが長時間実行されているため、PostgreSQL はログ先行書き込み (WAL) を解放できない可能性があります。pg_replication_slots ビューの詳細については、「PostgreSQL 15.4 ドキュメント」の「pg_replication_slots」を参照してください。

• 次のクエリを使用すると、データベース内のすべてのアクティブなクエリのリストと関連情報が返されます。

  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 フィールドには、各クエリのアクティブ期間が表示されます。長時間実行されているクエリは、これを使用して特定できます。

ソースでの高ワークロード

ソースの 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) の変更をフィルターして、関連する変更のみをレプリケーションインスタンスに送信します。AWS DMS で pglogical プラグインを使用する方法については、「pgglogical プラグインの設定」を参照してください。

高いネットワークスループット

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

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

Aurora PostgreSQL のスピルファイル

PostgreSQL バージョン 13 以降では、 logical_decoding_work_memパラメータによってデコードとストリーミングのメモリ割り当てが決まります。logical_decoding_work_mem パラメータの詳細については、PostgreSQL 13.13 ドキュメントの「PostgreSQL でのリソース消費」を参照してください。 PostgreSQL

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

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

ソースワークロードの増加による影響を減らすには、次の操作を行います。

• 長時間実行されるトランザクションを減らします。

• サブトランザクションの数を減らします。

• 1 つのトランザクションでテーブル全体を削除または更新するなど、大量のログレコードを生成するオペレーションは実行しないでください。代わりに小さなバッチで操作を実行します。

次の 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 デベロッパーガイド」の「論理デコードの作業メモリの調整」を参照してください。