AWS DMS を使用して PostgreSQL データベースをターゲットの RDS for PostgreSQL データベースに移行する際に使用すべきベストプラクティスはどのようなものですか?

簡単な説明

AWS DMS を使用して同種のデータベースを移行する場合は、エンジンのネイティブツール (pg_dump など) を使用して初期データをコピーします。その後、ターゲットで pg_restore を実行します。論理レプリケーションと COPY コマンドを使用することもできます。詳細については、「PostgreSQL データベースを Amazon RDS と Amazon Aurora に移行するためのベストプラクティス」を参照してください。

RDS for PostgreSQL データベースから別の RDS for PostgreSQL データベースに移行するには、スナップショットを作成し、そのスナップショットをターゲットとして復元します。詳細については、「RDS for PostgreSQL DB インスタンスのスナップショットを Aurora PostgreSQL DB クラスターに移行する」を参照してください。

AWS DMS フルロードを使用してソースデータベースからターゲットデータベースにすべてのデータを移行するには、時間がかかる場合があることに注意してください。次のような要因により、遅延が発生する可能性があります。

• 帯域幅
• 大量のデータをプッシュするためのソースキャパシティ
• バルクロードを保存、処理、転送するためのレプリケーションエンジンのキャパシティ
• ソースからデータを消費するためのターゲットキャパシティ

比較すると、変更レプリケーションに含まれているのはソースからターゲットへの変更のみであるため、このようなワークロードは非常に軽くなります。

現在のログシーケンス番号 (LSN) を作成して決定する

バックアップを作成する前に、AWS DMS タスクに変更の移行を開始する場所を指示するマーカーを取得する必要があります。

ソース PostgreSQL データベースで、これらのクエリを実行して現在の LSN を作成および決定します。

レプリケーションスロットを作成します。

SELECT * FROM
pg_create_logical_replication_slot('replication_slot_name','tset_decoding')

現在の LSN を取得します。

SELECT restart_LSN  FROM pg_replication_slots WHERE slot_name = 'replication_slot_name';

restart_LSN コマンドは、ソースからターゲットへの変更の移行を開始する場所を AWS DMS タスクに指示します。

解決方法

AWS DMS タスクを使用して PostgreSQL から PostgreSQL にデータを移行するには、次のベストプラクティスを使用します。

フルロード中は外部キーとトリガーを使用しない

フルロードが実行されているときは、移行のために外部キーとトリガーが含まれていないことを確認します。AWS DMS はテーブルをアルファベット順に移行しますが、どのテーブルが親テーブルで、どのテーブルが子テーブルかは認識しません。そのため、AWS DMS は最初に子テーブルを移行しようとする可能性があります。その後、AWS DMS は外部キーの違反を理由としてテーブルの移行を停止します。したがって、移行中には、ターゲット上の外部キーを抑制するか、含めないようにします。

トリガーは、ターゲット上のデータを破損する可能性のある複数のプロセスを実行するため、移行中にターゲット上に存在させてはなりません。カットオーバー時にトリガーを追加します。

JSON データの移行時にフル LOB モードをオンにする

JSON 形式で LOB を移行する場合は、JSON 形式が切り詰められないようにフル LOB モードをオンにします。制限付き LOB モードを使用すると、データの切り詰めが発生することがあります。その後、AWS DMS は、JSON の形式が間違っているためにテーブルが失敗することを確認します。

プライマリキーフィールドが TEXT データ型でないことを確認する

特にフル LOB モードがオンになっている場合は、プライマリキーフィールドが TEXT でないことを確認します。AWS DMS は TEXT データ型を LOB として扱うため、NULL の DUPLICATES が発生する可能性があります。そのため、フルロード中、AWS DMS はプライマリキーを NULL にしようとし、同じ値を持つテキスト列が多数存在するため、重複を報告します。このエラーは、「NULL not allowed on Primary Key」(プライマリキーでは NULL は許可されていません) として扱われることはなく、重複として扱われます。この問題は見つけて解決するのが難しい可能性があるため、この問題を回避するために、プライマリキーフィールドが TEXT でないことを必ず確認してください。

AWS DMS にターゲットテーブルの作成を許可する

フルロードが発生している場合は、AWS DMS がターゲットでテーブルを作成することを許可します。AWS DMS はテーブルを作成するときに、列の DEFAULT 値なしで一致するフィールドも作成します。列のデフォルト値は、AWS DMS で予期しない動作を引き起こす可能性があります。例えば、SERIAL は、このフィールドで値を自動作成する必要があるため、AWS DMS の移行を失敗させます。次の例を参照してください。

CREATE TABLE COMPANY (
   ID SERIAL PRIMARY KEY,
   NAME TEXT      NOT NULL);

ターゲットがこの例のように構成されている場合、PostgreSQL 内部では ID 列の値を生成したいと考えます。しかし、ソースには、問題の原因となる INSERT の値も含まれています。そのため、移行中は DEFAULTS がターゲットの一部となっていないことを確認してください。

タスクテーブルマッピングでパーティションをソーステーブルとして定義する

パーティションテーブルを移行するときは、親テーブルではなく、タスクテーブルマッピングのソーステーブルとしてパーティションを定義してください。これは、WAL ログがパーティション化されたテーブルの情報を保持するためです。親テーブルはフルロード中にのみ使用する必要があるため、CDC フェーズでは親テーブルを使用しないでください。CDC 中に親テーブルを定義すると、移行に影響する重複エラーが発生する可能性があります。

また、ターゲットテーブルをマッピングするときは、すべてのパーティションが親に再マッピングされていることを確認してください。これは、パーティションに自動的に配布するために親が使用されることを意味します。

PGLOGICAL を使用するときに、ソースですべてのファセットを定義する

移行のために PGLOGICAL を使用する場合は、ソースで必要なすべてのファセットを必ず定義してください。1 つのエリアをスキップすると、予期しない動作が発生します。この結果として発生する問題は、トラブルシューティングが非常に難しいため、PGLOGICAL を使用して移行を開始する前に、これらのエリアが定義されていることを確認してください。

Amazon RDS の場合は、次の項目を定義します。

パラメータグループ:

shared_preload_libraries = pglocical

データベースレベル:

create extension pglogical;

オンプレミスの場合は、次の項目を定義します。

postgresql.conf:

shared_preload_libraries = pglogical

データベースレベル:

create extension pglogical;

ソースで定義されているすべての PG プラグインがターゲットで定義されていることを確認する

ソースで定義するすべての PG プラグインがターゲットでも定義されていることを確認してください。これは、データの互換性と円滑な処理に役立ちます。

タスクが [Stop] (停止)/[Error] (エラー) 状態のままにならないようにする

タスクが [Stop] (停止) または [Error] (エラー) 状態のままで長時間が経過すると、レプリケーションスロットのストレージがいっぱいになります。

手動で作成したレプリケーションスロットをソースから削除する

レプリケーションスロットを手動で作成した場合は、移行の完了時にソースから削除します。レプリケーションスロットがソースに残っている場合は、サイズが累積され、ストレージがいっぱいになります。

プライマリキー/一意のインデックスを持つテーブルを移行する

移行しようとしているテーブルにプライマリキー/一意のインデックスがあることを確認するのがベストプラクティスです。テーブルにプライマリキーがない場合、UPDATE および DELETE ステートメントは WAL ログに記録されないため、テーブルに適用されない可能性があります。プライマリキーを持たないテーブルについては、REPLICATE IDENTITY FULL を使用しますが、これによってログに大量の情報が生成されることに注意してください。

---

関連情報

Using a PostgreSQL database as an AWS DMS source (AWS DMS のソースとしての PostgreSQL データベースの使用)

Targets for data migration (データ移行のターゲット)