PostgreSQL エンドポイントのトラブルシューティング - AWS Database Migration Service
ソースでのトランザクション実行時間が長いソースでの高ワークロード高いネットワークスループットAurora PostgreSQL のスピルファイル

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

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 Documentation」の「Resource Consumption in PostgreSQL」を参照してください。

論理レプリケーションは、トランザクションがコミットされるまで、すべてのトランザクションの変更をメモリに蓄積します。すべてのトランザクションに保存されているデータの量がデータベースパラメータ 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 デベロッパーガイド」の「論理デコード用のワーキングメモリの調整」を参照してください。