Amazon Aurora PostgreSQL での AWS DMS を使用したデータ移行における test_decoding プラグインと pglogical プラグインの比較

この記事は、”Comparison of test_decoding and pglogical plugins in Amazon Aurora PostgreSQL for data migration using AWS DMS” を翻訳したものです。

AWS Database Migration Service (AWS DMS) は、同種および異種のデータベース移行に使用される一般的なサービスです。 PostgreSQL から PostgreSQL への移行のような同種の移行では、DMS はネイティブのデータベースレプリケーション機能を使用するオプションを提供しています。これらのレプリケーション機能は、継続的なデータキャプチャ (CDC) の実装に不可欠で、これによってデータベース移行中のダウンタイムを削減できます。

この記事では、AWS DMS で使用可能な 2 つの PostgreSQL プラグインについて詳しく説明します。これらのプラグインオプションを比較し、テスト結果を共有することで、データベース管理者が移行時に各プラグインのベストプラクティスと利点を理解できるようにします。

前提条件

このポストは PostgreSQL とデータベース移行の専門家を対象としています。読者が以下の前提条件を備えていることを想定しています。

• AWS DMS の知識
• PostgreSQL と論理レプリケーションの理解
• Amazon CloudWatch や Amazon Aurora PostgreSQL-Compatible Edition などの AWS サービスの知識

概要

CDC 移行タスク (フルロードと CDC、または CDC のみ) の実行中、AWS DMS は論理レプリケーションスロットを使用して、ログがデコードされるまでレプリケーション用の WAL ログを保持します。主に 2 つの異なる論理デコードプラグインをサポートしています。

1. test_decoding: postgresql-contrib パッケージに含まれる出力プラグインです。
2. pglogical: 2nd Quadrant (現在は EnterpriseDB) によって開発された PostgreSQL 拡張機能で、パブリッシャー/サブスクライバーアプローチに基づいています。

CDC オペレーションのパフォーマンスに影響を与える重要なパラメータの 1 つが、PostgreSQL パラメータの logical_decoding_work_mem です。このブログ投稿の最初のセクションでは、クエリレベルでのディスク溢れを追跡することで、このパラメータをチューニングする方法を示します。ディスク溢れはレプリケーションと全体的なデータベースエンジンのパフォーマンスに大きな影響を与える可能性があります。

第 2 セクションでは、test_decoding と pglogical デコーディングプラグイン間のパフォーマンスへの影響度を詳細に比較します。

セクション 1: 論理レプリケーション中のディスク上への一時書き出しの追跡

ロングランニングトランザクションが関係するシナリオでは、AWS DMS はトランザクションがコミットされるまで待機してから、レプリケーションスロットから後続のトランザクションを処理します。このプロセス全体を通じて、test_decoding と pglogical プラグインは、ライトアヘッドログ (WAL) 内のすべてのトランザクションをデコードするために積極的に動作します。 logical_decoding_work_mem バッファが満杯になると、超過分はディスクに書き込まれます。 pg_stat_replication_slots ビューを使用して、これらのディスク書き込みの累積効果を監視できます。

以下のクエリは、spill_count や spill_bytes などのスピルファイルの詳細を示します。

postgres=> select * from pg_stat_replication_slots where slot_name = 'replication_slot';
-[ RECORD 1 ] +-----------------
 slot_name    | replication_slot 
 spill_txns   | 1 
 spill_count  | 53 
 spill_bytes  | 3544080818 
 stream_txns  | 0 
 stream_count | 0 
 stream_bytes | 0 
 total_txns   | 1 
 total_bytes  | 66327798 
 stats_reset  | 

logical_decoding_work_mem パラメータは、ロジカルデコーディングプロセスのメモリ割り当てを指定し、デコーディングおよびストリーミングメカニズムを制御します。ロジカルデコーディング処理内では、WAL レコードが SQL ステートメントに変換され、DMS タスクに送信されます。logical_decoding_work_mem で割り当てられたメモリ内にトランザクション全体が収まることを確認することが重要です。メモリ容量を超過するとレコードがディスクに溢れ、これは work_mem とトランザクションの一時ファイルの影響と同様に、最終的にプロセス全体の速度低下につながるためです。

ワークロードの要件に合わせて logical_decoding_work_mem パラメータを最適化および調整することで、バッチロード中のディスクへの書き込みによる負荷を大幅に軽減し、より安定した、より効率的なレプリケーションプロセスを実現できます。これらの仕組みを理解することが設定とリソース割り当ての最適化に寄与し、結果として AWS DMS 内の CDC プロセスのパフォーマンスと耐障害性の向上に貢献します。

長時間実行されるワークロード中に logical_decoding_work_mem パラメータを調整するには、aurora_stat_file() 関数を使用してスピルファイル情報をキャプチャしながら、Aurora PostgreSQL のメモリパラメータチューニングガイドを参照することをお勧めします。

このソリューションを実装するための大まかなステップは以下の通りです。

1. データベースの認証情報を使用してソース Aurora PostgreSQL に接続します。
2. スピルファイル情報を収集するために、以下のような新しいテーブルを作成します。

CREATE TABLE spill_file_tracking AS 
    SELECT now() AS spill_time,*
    FROM aurora_stat_file()
    WHERE filename LIKE '%<all_slot_name>%';

3. aurora_stat_file() から結果セットをキャプチャします

INSERT INTO spill_file_tracking 
  SELECT now(),*
  FROM aurora_stat_file()
  WHERE filename LIKE '%<all_slot_name>%';

4. \watch を使用して、必要な間隔に基づいてスピルファイル情報を継続的にキャプチャします。次のコマンドは、1 秒ごとに現在のクエリバッファを繰り返します。

\watch 1

5. データベースへの別の PostgreSQL セッションを開き、以下のクエリを実行してスピルファイルの使用状況に関する情報を取得します。

SELECT spill_time, split_part (filename, '/', 2)
    AS slot_name, count(1)
    AS spills, sum(used_bytes)
    AS slot_total_bytes, pg_size_pretty(sum(used_bytes))
    AS slot_total_size FROM spill_file_tracking 
  GROUP BY 1,2 ORDER BY 1 ;

スピルファイルの詳細を確認した後、\watch 1 セッションに戻り、Ctrl + C を押して監視を停止します。

この情報により、特定のスロットで発生するディスク溢れの数と合計サイズを理解でき、これをもとに logical_decoding_work_mem パラメータを微調整してディスク溢れを削減できます。これはレプリケーションスロットでのデコードプロセスの改善に役立ちます。

セクション 2: test_decoding と pglogical デコード プラグイン間のパフォーマンス上の影響比較

このセクションでは、AWS DMS で主に使用される 2 つの PostgreSQL プラグインの利点と欠点を比較するために、異なるテストシナリオを確認します。

ソリューション概要

以下の図は、test_decoding と pglogical を比較およびテストするために作成されたリソースのアーキテクチャ概要を示しています。

設定

1. Aurora PostgreSQL のプロビジョニング
2. PostgreSQL をソースとして AWS DMS を設定する
3. AWS DMS を使用して Aurora PostgreSQL でロジカルレプリケーション用の pglogical プラグインを設定する
4. test_decoding 出力プラグインを使用してレプリケーションスロットを作成する

注:

• この比較では、r6g.2xlarge インスタンス上の Aurora PostgreSQL 14.9 と AWS DMS 3.5.2 を使用しました。
  ロジカルデコーディング用プラグイン以外は、ストレージ、ネットワーク、DB パラメータが両方のケースで同じです。
• AWS DMS はロジカルデコーディングに test_decoding または pglogical プラグインを使用します。
  ソース PostgreSQL データベースで pglogical プラグインが利用可能な場合、DMS は pglogical を使用してレプリケーションスロットを作成します。そうでない場合は、test_decoding プラグインが使用されます。

テストでは、2 つのテーブルを使用します。

• seat（座席）

\d seat 
                          Table "dms_sample.seat"
      Column       |         Type          | Collation | Nullable | Default 
-------------------+-----------------------+-----------+----------+---------
 sport_location_id | double precision      |           | not null |
 seat_level        | smallint              |           | not null |
 seat_section      | character varying(15) |           | not null |
 seat_row          | character varying(10) |           | not null |
 seat              | character varying(10) |           | not null |
 seat_type         | character varying(15) |           |          |
 Indexes:
    "seat_sport_location_pk" PRIMARY KEY, btree (sport_location_id)

• ticket_purchase_hist（チケット購入履歴）

\d ticket_purchase_hist 
                          Table "dms_sample.ticket_purchase_hist"
          Column          |              Type              | Collation | Nullable | Default 
--------------------------+--------------------------------+-----------+----------+---------
 sporting_event_ticket_id | double precision               |           | not null |
 purchased_by_id          | double precision               |           | not null |
 transaction_date_time    | timestamp(0) without time zone |           | not null |
 transferred_from_id      | double precision               |           |          |
 purchase_price           | numeric(8,2)                   |           | not null |
 Indexes:
    "ticket_purchase_hist_pk" PRIMARY KEY, btree (sporting_event_ticket_id, purchased_by_id, transaction_date_time)
    "tph_purch_by_id" btree (purchased_by_id)
    "tph_trans_from_id" btree (transferred_from_id)

注: これらのテーブルは、pgbench カスタムスクリプトと random() や generate_series() などの PostgreSQL 関数を使用して、データの投入や DML 負荷の生成が行われています。

上記のテーブルに対して、2 つのデコードプラグインを使用して 2 つのテストを実施しました。

• テスト 1: seat テーブルに対してトランザクションを実行します。このテーブルはレプリケーションされておらず、AWS DMS CDC タスクに含まれていません。このテーブルは非 CDC テーブルと呼ばれます。
• テスト 2: ticket_purchase_hist テーブルに対してトランザクションを実行します。このテーブルは複製され、AWS DMS CDC タスクの一部です。このテーブルは CDC テーブルと呼ばれます。

各テストケースについて、指定された Amazon CloudWatch メトリクスを使用して、各プラグインのパフォーマンスを観察・分析します。

1. ReplicationSlotDiskUsage: Amazon Relational Database Service (Amazon RDS) の CloudWatch メトリクスで、Amazon RDS と Aurora for PostgreSQL インスタンスのレプリケーションスロットで使用されるディスク使用量に関する情報を提供します。
2. TransactionLogsDiskUsage: Amazon RDS の CloudWatch メトリクスで、Amazon RDS と Aurora インスタンスのトランザクションログで使用されるディスク使用量に関する情報を提供します。
3. CDCLatencySource: AWS DMS の CloudWatch メトリクスで、ソースデータベースからレプリケーションホストへのデータ複製（ CDC ）のレイテンシーに関する情報を提供します。
4. CDCLatencyTarget: AWS DMS の CloudWatch メトリクスで、レプリケーションホストからターゲットデータベースへのデータ複製（ CDC ）のレイテンシーに関する情報を提供します。
5. CDCThroughputRowsSource: AWS DMS レプリケーションタスクの CloudWatch メトリクスで、ソースデータベースからキャプチャされたデータ変更（ CDC ）の量を、1 秒あたりの行数で提供します。
6. CDCIncomingChanges: Amazon RDS の CloudWatch メトリクスで、AWS DMS がソースデータベースからキャプチャした受信データ変更（ CDC ）の数に関する情報を提供します。

テスト 1: 非 CDC テーブルへのロード

非 CDC テーブルには、2 つのテストケースがあります。

1. レプリケーションスロット test_decoding を使用した非 CDC テーブルへのロード
2. レプリケーションスロット pglogical を使用した非 CDC テーブルへのロード

test_decoding を使用したレプリケーションスロット

Test 1-A では、レプリケーションスロットへの影響を理解するために、seat テーブルでロングランニングトランザクションを開始しました。次の表に、test_decoding を使用したレプリケーションスロットの設定を示します。

test_decoding: database-1 から database-2 への移行

以下の 2 つのグラフは、ソースクラスタのプライマリインスタンスの CloudWatch メトリクスである ReplicationSlotDiskUsage と TransactionLogsDiskUsage を示しています。

メトリクス名: ReplicationSlotDiskUsage

以下のグラフから、test_decoding プラグインを使用する場合、ロングランニングトランザクション中にソース側のデータベースのディスク使用量が増加したことが観察できます。

メトリクス名: TransactionLogsDiskUsage

次のグラフに基づいて、ロングランニングトランザクション中にソースデータベースのトランザクションログのディスク使用量が増加していることが分かります。

以下のグラフは、AWS DMS タスク (testdecodingOnNonCDCTable) の Amazon CloudWatch メトリクスの CDCLatencySource、CDCLatencyTarget、CDCThroughputRowsSourceを示しています。

メトリクス名: CDCLatencySource

メトリクス名: CDCLatencyTarget

次のグラフから、ターゲット上のレプリケーションスロットのディスク使用量の増加に伴い、レイテンシーが増加していることがわかります。

メトリクス名: CDCThroughputRowsSource

次のグラフでは、CDC の対象外のテーブルでトランザクションが発生しているため、スループットが 0 となっていることが確認できます。

AWS DMS タスクの CloudWatch メトリクスで、前述のロングランニングトランザクションのレイテンシーが生じることが確認されました。レイテンシーの主な原因は、論理的にデコードされたすべてのデータが AWS DMS に送信され、そこで定義されたルールセットに基づいてフィルタリングされるためです。この場合、CDC の対象外のテーブルに負荷がかかりました。 test_decoding プラグインを使用する場合、CDC テーブルフィルターはレプリケーションスロットで適用されず、AWS DMS で適用されるため、レイテンシーが発生します。

pglogical を使用したレプリケーションスロット

テスト 1-B では、pglogical プラグインの影響を理解するために、seat テーブルでロングランニングトランザクションを開始しました。
次の表は、pglogical でレプリケーションスロットに用いた構成を示しています。

以下の CloudWatch グラフは、ソースクラスタのライターインスタンスの ReplicationSlotDiskUsage と TransactionLogsDiskUSage を示しています。

pglogical: database-3 から database-4 への移行

メトリクス名: ReplicationSlotDiskUsage

メトリクス名: TransactionLogsDiskUsage

メトリクス名: CDCLatencySource

以下のグラフは、AWS DMS タスク (pglogicalOnNonCDCTable) の CDCLatencySource、CDCLatencyTarget、および CDCThroughputRowsSource）のメトリクスを示しています。

メトリクス名: CDCLatencyTarget

メトリクス名: CDCThroughputRowsSource

pglogical プラグインを使用した同じロングランニングトランザクションのレプリケーションでは、AWS DMS タスクメトリクスに遅延は観察されません。遅延が観察されない理由は、DMS がこれらの変更を使用する前に、論理的にデコードされたデータがレプリケーション対象外のテーブル (CDC タスクの一部ではないテーブル) に対してフィルタリングされるためです。

テスト 1 における test_decoding と pglogical の比較

以下のグラフは、両方のユースケースにおけるソースインスタンスの CloudWatch メトリクスの比較を示しています。

オレンジ色の線は test_decoding プラグインを使用して database-1 から取得したデータを表し、青色の線は pglogical プラグインを使用して database-3 からのデータを示しています。ほぼ平坦なオレンジ色の線と比較して、青色の線に急激な低下が見られます。この動作は、レプリケーションスロットレベルで pglogical プラグインが使用するフィルタリングメカニズムによるものです。

CDC プロセスの一部ではないテーブルに関連するトランザクションはフィルタリングされるため、青い線に見られる急激な低下が生じます。一方、test_decoding プラグインは CDC 対象かどうかによってトランザクションをフィルタリングしないため、CDC プロセスの一部ではないテーブルでトランザクションが発生していても、平坦な線が続きます。

テスト 1 の観察結果

比較メトリクスレポートを確認したところ、test_decoding プラグイン (database-1-instance-1) を使用した PostgreSQL レプリケーションスロットは、デコード後に DMS タスクがトランザクション全体を消費するのを待機していることが観察されました。pglogical プラグイン (database-3-instance-1) では同じことは起こりませんでした。また、test_decoding レプリケーションの DMS タスクメトリクスでレイテンシーが観察されましたが、pglogical レプリケーションではそのようなことはありませんでした。両方の観察結果の理由は、pglogical プラグインを使用する場合、非 CDC テーブルのレプリケーションスロットでフィルタリングが行われていたためです。これは test_decoding プラグインでは起こりませんでした。

ロングランニングトランザクション中に、遅延した並列挿入ステートメントが CDC テーブルで実行される場合、test_decoding によるこれらの挿入ステートメントの処理遅延の増加が観察されました。これは、test_decoding がレプリケーションスロットで変更をフィルタリングできないため、WAL 全体がデコードされて AWS DMS タスクにフィルタリング用に送信されるためです。トランザクションの順序を保持するために、遅延した挿入ステートメントはロングランニングトランザクションと共にデコードされますが、フィルタリングは AWS DMS タスクがレプリケーションスロットの変更を読み取った後にのみ実行および適用されます。DMS タスクは、ロングランニングトランザクションのコミットが確認された後にこれらの変更を読み取るため、レイテンシが生じます。一方、pglogical では replication_slot でフィルタリングが実行されるため、CDC テーブルへの並列 DML アクティビティは AWS DMS タスクによって読み取られ適用されます。非 CDC テーブルのロングランニングトランザクションが pglogical レプリケーションスロットによってデコードされている場合でも、CDC テーブルの他の DML アクティビティは妨げられません。この主な理由は、現在デコード中の非 CDC テーブルのロングランニングトランザクションが、pglogical レプリケーションスロットで現在認識されている DMS タスクによって読み取られる必要がないためです。したがって、CDC テーブルのみのトランザクション順序を保持し、変更は DMS タスクによって読み取られ適用されます。

テスト 2: CDC テーブルへの負荷

このテストシナリオでは、database-1 (ソース) に test_decoding プラグインを使用して新しいレプリケーションスロットを作成し、それに対応する新しい AWS DMS エンドポイントと新しい DMS タスクを作成します。これには、ロードが開始される CDC テーブルが含まれます。また、database-3 (ソース) に pglogical プラグインを使用して新しいレプリケーションスロットを作成し、それに対応する新しい DMS エンドポイントと新しい DMS タスクを作成します。これには CDC テーブルが含まれます。

前のテストと同様に、2 つのケースをテストします。

1. レプリケーションスロット test_decoding を使用して CDC テーブルへのロード
2. レプリケーションスロット pglogical を使用して CDC テーブルへのロード

test_decoding を使用したレプリケーションスロット

テスト 2-A では、ticket_purchase_hist テーブルでロングランニングトランザクションを開始しました。このテーブルはレプリケーション（ CDC タスクの一部）の対象であり、レプリケーションスロットへの影響を理解することを目的としています。次の表は、test_decoding を使用したレプリケーションスロットの構成を示しています。

test_decoding: database-1 から database-2 への移行

以下のグラフは、ソースクラスタのライターインスタンスについて、CloudWatch の ReplicationSlotDiskUsage と TransactionLogsDiskUsage メトリクスを示しています。

メトリクス名: ReplicationSlotDiskUsage

以下のグラフに示すように、test_decoding プラグインを使用する場合、ロングランニングトランザクション中にソースデータベースのディスク使用量が増加することが観察されました。

メトリクス名: TransactionLogsDiskUsage

以下のグラフに示すように、ロングランニングトランザクション中に、ソースデータベースのトランザクションログのディスク使用量が増加することが確認されます。

以下のグラフは、CDCIncomingChanges、CDCLatencySource、CDCLatencyTarget、および CDCThroughputRowsSource について、AWS DMS タスク (testdecodingOnCDCTable) の CloudWatch メトリクスを示しています。

メトリクス名: CDCIncomingChanges

以下のグラフに示すように、トランザクションテーブルが CDC の一部であるため、ソースのレプリケーションスロットでのディスク使用量の増加に伴い、受信する変更数の増加が観察されます。

メトリクス名: CDCLatencySource

以下のグラフから、ソースのレプリケーションスロットのディスク使用量が増加するとレイテンシーも増加することがわかります。

メトリクス名: CDCLatencyTarget

以下のグラフに示すように、ターゲットのレプリケーションスロットのディスク使用量が増加するにつれて、レイテンシーが増加することが確認されます。

メトリクス名: CDCThroughputRowsSource

以下のグラフに示すように、CDC の対象テーブルでトランザクションが発生しているため、スループットの増加が見られます。

以下は AWS DMS コンソールのスクリーンショットで、ticket_purchase_hist テーブルの INSERT 統計を示しています。

CloudWatch メトリクスから、AWS DMS タスクに関連するロングランニングトランザクションのレイテンシーが明らかになります。トランザクションに関連するテーブルを CDC プロセスに組み込んでいるため、プラグインがレプリケーションスロットレベルまたは AWS DMS レベルでデータをフィルタリングするかどうかに関わらず、デコードされたすべてのデータが AWS DMS に送信されます。これは、全てのトランザクションが CDC プロセスの対象テーブルで発生しているためです。その結果、pglogical プラグインを使用している場合でも、次のグラフでレイテンシーが観察されることが予想されます。

pglogical を使用したレプリケーションスロット

Test 2-B では、pglogical プラグインを使用した同様の構成で生成されるレイテンシーを観測することを目的としました。次の表は、pglogical を使用したレプリケーションスロットに使用された構成を示しています。

Pglogical: database-3 から database-4 へのマイグレーション

以下のグラフは、ソースクラスタのインスタンスの CloudWatch メトリクスを示しています。

メトリクス名: ReplicationSlotDiskUsage

以下のグラフに基づいて、pglogical プラグインを使用する場合、ロングランニングトランザクション中にソースデータベースのディスク使用量が増加することが確認できます。

メトリクス名: TransactionLogsDiskUsage

次のグラフに基づいて、ロングランニングトランザクション中にソースデータベースのトランザクションログのディスク使用量が増加していることが確認できます。

以下のグラフは、DMS タスク (pglogicalOnCDCTable) の CloudWatch メトリクスを示しており、CDCIncomingChanges、CDCLatencySource、CDCLatencyTarget、および CDCThroughputRowsSource についてのメトリクスが含まれています。

メトリクス名: CDCIncomingChanges

以下のグラフに示すように、CDC の対象となっているテーブルでトランザクションが発生しているため、受信する変更の数が増加し、それに伴ってソースのレプリケーションスロットのディスク使用量も増加していることが確認できます。

メトリクス名: CDCLatencySource

以下のグラフに示すように、CDC の対象となっているテーブルでトランザクションが発生しているため、ソースのレプリケーションスロットのディスク使用量が増加するにつれて、遅延が増加することが確認できます。

メトリクス名: CDCLatencyTarget

以下のグラフに示すように、CDC に含まれるテーブルでトランザクションが発生しているため、ソースのレプリケーションスロットのディスク使用量の増加に伴って、レイテンシーが増加することが観察されます。

メトリクス名: CDCThroughputRowsSource

以下のグラフに示すように、CDC で監視対象となっているテーブルでトランザクションが発生しているため、スループットが増加していることが見受けられます。

以下のスクリーンショットは、AWS DMS コンソールの ticket_purchase_hist テーブルの INSERT 統計を示しています。

予想通り、pglogical プラグインでも CloudWatch メトリクスに同様のトレンドが見られます。

テスト 2 における test_decoding と pglogical の比較

以下の CloudWatch メトリクスグラフは、データ移行タスク中に test_decoding および pglogical プラグインを使用する場合の ReplicationSlotDiskUsage と TranslationLogsDiskUsage のリソース利用パターンを示しています。設定をおさらいすると、database-1 から database-2 への移行には test_decoding を使用し、database-3 から database-4 への移行には pglogical を使用しました。これらのグラフを分析することで、リソース消費を比較し、特定の移行シナリオに対してより効率的なプラグインを特定できます。

オレンジ色の線は test_decoding プラグインを使用して database-1 から取得したデータを表し、青色の線は pglogical プラグインを使用して database-3 からのデータを示しています。分析によると、test_decoding と pglogical のグラフは同様のパターンを示すはずです。しかし、青色の線の急激な低下が発生しています。これはDMS タスクに 2 つのテーブルが存在することに起因しており、1 つのテーブルは CDC の対象で、もう 1 つは対象外であることが原因と考えられます。 pglogical はレプリケーションスロットレベルでデータをフィルタリングするため、グラフに急激な低下が生じます。

テスト 2 の観察結果

Test 2 では、CDC テーブルに対して負荷を開始した場合、test_decoding と pglogical を比較しても大きな利点は見られませんでした。両デコードプラグインは、様々な CloudWatch メトリクスで同様のトレンドを示しました。

DMS タスクの数を増やすと、ReplicationSlotDiskUsage が増加し、ディスク溢れが増加します。これはロングランニングトランザクションが原因で、レイテンシーの問題が生じる可能性があります。

まとめ

このポストでは、セクション 1 で aurora_stat_file() 関数とトラッキングテーブルを使用してスピルファイル情報を効率的にキャプチャする方法を説明しました。これは、logical_decoding_work_mem パラメータのチューニングと AWS DMS CDC プロセスのパフォーマンス向上に役立ちます。セクション 2 では、特定のワークロードを使用して Amazon Aurora PostgreSQL 互換インスタンス間でデータをレプリケートする際に、AWS DMS で test_decoding プラグインと pglogical プラグインを比較しました。当社の検証結果に基づくと、2 つのプラグインのそれぞれに特定の利点があり、これらのユースケースの一部で AWS DMS CDC パフォーマンスを向上させるのに役立つと言えます。

pglogical:

• AWS DMS がボトルネック (停止したタスク、高レイテンシーなど) に遭遇した場合、pglogical はレプリケーションスロットで CDC 以外のテーブルをフィルタリングすることで、test_decoding よりも優位性があります。
• pglogical プラグインはソースレプリケーションスロットでデータをフィルタリングするため、特にオンプレミスまたは他のパブリッククラウドからの移行時に、より高いネットワーク帯域幅が必要な場合に、必要なネットワークスループットをより効率的に削減できます。
• pglogical プラグインは、CDC 以外のテーブルのフィルタリング方法により、すべてのテーブルが CDC プロセスの一部である必要がないワークロードに適しています。
• デコードプロセス中にレプリケーションスロットでボトルネックが観察される場合、logical_decoding_work_mem パラメータを調整することでディスク溢れを削減できます。また、ロングランニングトランザクションを分割することで、レプリケーションスロットでのディスク溢れを削減できます。

test_decoding:

• データベース内のテーブルをフィルタリングする必要がない場合、つまりソース PostgreSQL データベースのすべてのテーブルが CDC プロセスの対象となる場合は、test_decoding を使用できます。
• 更新または削除トランザクションで行全体をキャプチャして転送する必要がある場合は、test_decoding が推奨されます。
• データベースで定義されているほとんどのテーブルに主キー制約がない場合は、test_decoding が推奨されます。更新または削除操作時に行全体が移行されるためです。

適切な論理デコードプラグインを選択することに加えて、以下を含むマイグレーションのベストプラクティスに従うことが重要です。

1. 適切なインスタンスサイズの選択 (AWS DMS レプリケーションインスタンス、Aurora PostgreSQL)
2. 移行タスクの効果的な設計
3. 適切なストレージおよびネットワークコンポーネントの選択
4. アラート付きモニタリングの設定

ご質問やご提案がある場合は、コメント欄にお寄せください。

著者について

Viswanatha Shastry Medipalli は AWS ProServe チームのシニアアーキテクトです。データベース移行に関する幅広い専門知識と経験を有しており、複雑なビジネス要件に対応する多くの成功したデータベースソリューションを設計・構築してきました。Oracle、SQL Server、PostgreSQL データベースを使用したレポーティング、ビジネスインテリジェンス (BI) アプリケーション、開発サポート向けのソリューション構築実績があります。自動化とオーケストレーションに関する知識も豊富で、オンプレミスデータベースから Amazon への同種および異種の移行が専門分野です。

Swanand Kshirsagar は AWS Professional Services Expert Services 部門のアーキテクトです。
クライアントと協力して、AWS クラウド上でスケーラブルで堅牢で、セキュリティに準拠したソリューションの設計と実装を専門としています。
主な専門知識は、同種および異種の両方の移行を含むシームレスな移行を調整、オンプレミスデータベースの Amazon RDS および Amazon Aurora PostgreSQL への効率的な移行を支援することにあります。
Swanand はカンファレンスでセッションを実施したり、ワークショップを開催したりしてきました。

Abhilash Sajjaは、AWS の Professional Services チームのデータベースコンサルタントです。
顧客とパートナーの AWS クラウドへの移行を支援しており、データベースの移行と現代化プログラムに注力しています。
様々なデータベーステクノロジーの経験を活かして、オンプレミスのデータベース環境を AWS データストアに移行する顧客に対して、ガイダンスと技術サポートを提供しています。

翻訳はソリューションアーキテクト石本が担当しました。原文はこちらです。