PostgreSQL エンドポイントのトラブルシューティング - AWS データベース移行サービス
ソースでのトランザクション実行時間が長いソースでの高ワークロード高いネットワークスループットAurora Postgre のスピルファイルSQL

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

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

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

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

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

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

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

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

    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 の場合、PSQLクライアントバージョン 11 以降を使用して次のクエリを使用します (クエリ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 プラグインの設定。

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

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

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

Aurora Postgre のスピルファイルSQL

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

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

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

ソースワークロードの増加による影響を軽減するには、以下を実行します。

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

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

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

次の CloudWatch メトリクスを使用して、ソースのワークロードをモニタリングできます。

  • TransactionLogsDiskUsage: 論理 によって現在占有されているバイト数WAL。この値は、論理レプリケーションスロットが新しい書き込みのペースに追いつくことができない場合、または長時間実行されるトランザクションが古いファイルのガベージコレクションを妨げる場合、単調に増加します。

  • ReplicationSlotDiskUsage: 論理レプリケーションスロットが現在使用しているディスク容量。

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

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

現在のトランザクションオーバーフローは、 aurora_stat_file関数で確認できます。詳細については、「Amazon Relational Database Service デベロッパーガイド」の「論理デコードの作業メモリの調整」を参照してください。 Amazon Relational Database Service