翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS DMS の同種データ移行での PostgreSQL データベースからのデータの移行
同種データ移行 を使用して、セルフマネージド型 PostgreSQL データベースを RDS for PostgreSQL または Aurora PostgreSQL に移行できます。AWS DMS は、データ移行用のためのサーバーレス環境を作成します。AWS DMS はさまざまなネイティブ PostgreSQL データベースツールを使用して、さまざまなタイプのデータ移行に対応します。
[フルロード] タイプの同種データ移行の場合、AWS DMS は pg_dump を使用してソースデータベースからデータを読み取り、サーバーレス環境にアタッチされているディスクに保存します。すべてのソースデータの読み取りを完了した後、AWS DMS はターゲットデータベースの pg_restore を使用してデータを復元します。
[フルロードと変更データキャプチャ (CDC)] タイプの同種データ移行の場合、AWS DMS は pg_dump を使用し、ソースデータベースからテーブルなしでスキーマオブジェクトを読み取り、サーバーレス環境にアタッチされているディスクに保存します。次に、ターゲットデータベースの pg_restore を使用してスキーマオブジェクトを復元します。AWS DMS が pg_restore プロセスを完了した後、Initial Data Synchronization オプションを使用して論理レプリケーションのパブリッシャーモデルとサブスクライバーモデルに自動的に切り替え、最初のテーブルデータをソースデータベースからターゲットデータベースに直接コピーし、継続的なレプリケーションを開始します。このモデルでは、単一または複数のサブスクライバーがパブリッシャノード上の単独または複数のパブリケーションにサブスクライブします。
変更データキャプチャ (CDC) タイプの同種データ移行の場合、AWS DMS がレプリケーションを開始するには、ネイティブ開始点が必要です。ネイティブ開始点を指定すると、AWS DMS はその時点からの変更をキャプチャします。または、データ移行設定で [すぐに] を選択すると、実際のデータ移行の開始時にレプリケーションの開始点を自動的にキャプチャできます。
注記
CDC のみの移行を正常に実行するには、ソースデータベースのすべてのスキーマとオブジェクトがターゲットデータベースに既に存在している必要があります。ただし、ターゲットにはソースには存在しないオブジェクトが含まれている場合があります。
次のコード例を使用すると、PostgreSQL データベースのネイティブ開始点を取得できます。
select confirmed_flush_lsn from pg_replication_slots where slot_name=‘migrate_to_target';
このクエリは、PostgreSQL データベースの pg_replication_slots ビューを使用してログシーケンス番号 (LSN) の値を取得します。
AWS DMS が PostgreSQL の同種データ移行のステータスを [停止済み]、[失敗]、[削除済み] に変更しても、パブリッシャーとレプリケーションは削除されません。移行を再開しない場合は、次のコマンドを使用してレプリケーションスロットとパブリッシャーを削除します。
SELECT pg_drop_replication_slot('migration_subscriber_{ARN}'); DROP PUBLICATION publication_{ARN};
次の図は、AWS DMS で同種データ移行を使用して PostgreSQL データベースを RDS for PostgreSQL または Aurora PostgreSQL に移行するプロセスを説明しています。
同種データ移行のソースとしての PostgreSQL データベースの使用のベストプラクティス
FLCDC タスクのサブスクライバー側の初期データ同期を高速化するには、
max_logical_replication_workersとmax_sync_workers_per_subscriptionを調整する必要があります。これらの値を増加させると、テーブルの同期速度が向上します。max_logical_replication_workers – 論理レプリケーションワーカーの最大数を指定します。これには、サブスクライバー側の適用ワーカーとテーブル同期ワーカーの両方が含まれます。
max_sync_workers_per_subscription –
max_sync_workers_per_subscriptionを増加させると、テーブルあたりのワーカー数ではなく、並列に同期されているテーブルの数にのみ影響があります。
注記
max_logical_replication_workersはmax_worker_processesを超えず、max_sync_workers_per_subscriptionはmax_logical_replication_workers以下である必要があります。大きなテーブルを移行する場合、選択ルールを使用して別々のタスクに分割することを検討してください。例えば、大きなテーブルを個別のタスクに分割し、小さなテーブルを別の単一のタスクに分割できます。
サブスクライバー側のディスクと CPU の使用率をモニタリングして、最適なパフォーマンスを維持します。
