AWS DMS を使用してソース RDS MySQL データベースをターゲット RDS MySQL データベースに移行する際に従うべきベストプラクティスは何ですか?

所要時間3分

AWS Database Migration Service (AWS DMS) を使用して MySQL データベース用 Amazon Relational Database Service (Amazon RDS) に移行する MySQL データベースがあります。ソース MySQL データベースとターゲット MySQL データベース間の移行を最適化するために使用できるベストプラクティスは何ですか?

簡単な説明

AWS DMS を使用して、ソースデータストアからターゲットデータストアにデータを移行できます。これら 2 つのデータストアはエンドポイントと呼ばれます。1 つの MySQL データベースから別の MySQL データベースなど、同じデータベースエンジンを使用するソースエンドポイントとターゲットエンドポイント間で移行できます。

AWS DMS はターゲットスキーマオブジェクトを作成しますが、データをソースから効果的に移行するために必要な最小限のオブジェクトのみを作成します。そのため、AWS DMS は、テーブル、プライマリキー、場合によっては一意のインデックスを作成しますが、セカンダリインデックス、非プライマリキーの制約、データのデフォルトなどのオブジェクトは作成しません。AWS DMS が移行する内容の詳細については、「AWS DMS の概要」を参照してください。

移行前にターゲットデータベースにテーブルを事前に作成する

デフォルトのデータ定義を保持するには、移行前にターゲットデータベースにテーブルを事前に作成します。実行する移行のタイプに応じて、次のいずれかの方法を使用します。

MySQL から MySQL など、同種マイグレーションの場合は、mysqldump などのネイティブデータベースエンジンユーティリティを使用してテーブル定義をエクスポートします。次に、これらのテーブル定義をデータのないターゲットにインポートします。テーブル定義が作成されたら、ターゲットテーブル準備モードを TRUNCATE_BEFORE_LOAD に設定した AWS DMS タスクを使用してデータをロードします。
異なるデータベースエンジン間での移行には、AWS Schema Conversion Tool (AWS SCT) を使用します。この方法は、同種データベースにも使用できます。AWS SCT はソースデータベースとターゲットデータベースに接続し、既存のデータベーススキーマをあるデータベースエンジンから別のデータベースエンジンに変換します。AWS SCT を使用して、デフォルトのデータ定義をそのままにして、ターゲットデータベースにテーブルを事前に作成できます。次に、ターゲットテーブル準備モードを TRUNCATE_BEFORE_LOAD に設定した AWS DMS タスクを使用してデータをロードします。詳細については、「AWS SCT を使用してスキーマを変換する」を参照してください。

解決方法

MySQL から MySQL への AWS DMS 移行のベストプラクティスに従う

MySQL ソースデータベースから MySQL ターゲットデータベースにデータを移行する場合は、次のベストプラクティスを使用します。

移行中は、ターゲットデータベースのバックアップとデータベース固有のログ (バイナリ、一般、監査など) をオフにします。必要な場合は、問題をトラブルシューティングするために再度オンにできます。
移行中は、ターゲットデータベースでトリガー、その他の cron ジョブ、イベントスケジューラをオフにします。
AWS DMS の移行を実行するときは、ターゲット Amazon RDS データベースでマルチ AZ を使用しないでください。
移行を実行するときは、他の外部クライアントトラフィックをターゲットデータベースに印加しないでください。
移行中のリソース競合を回避するために、必要な CPU、メモリ、ストレージ、および IOPS を使用して AWS DMS レプリケーションインスタンス、ソース、およびターゲットデータベースをプロビジョニングします。
移行を開始する前に、AWS DMS 変更データキャプチャ (CDC) を使用するための前提条件に合うようにソースデータベースを設定します。
移行には、制限付き LOB やインライン LOB など、最適化された LOB 設定を使用します。
ソースデータベースにワークロードが大きいテーブルが多数含まれている場合は、テーブルを複数のタスクに分割します。ソースデータベースでのサイズ、アプリケーショントラフィックのパターン、および LOB 列の有無に基づいてテーブルを分割します。テーブルに、ソースでの書き込みトラフィックが多い LOB (TEXT または JSON) 列が多数ある場合は、テーブル用に別のタスクを作成します。トランザクションの一貫性はタスク内で維持されるため、別々のタスクのテーブルが共通のトランザクションに関与しないことが重要です。
負荷の大きいソーステーブルには並列フルロードメカニズムを使用して、移行時間を短縮します。詳細については、「選択したテーブルおよびビューさらにコレクションで並列ロードを使用する」を参照してください。
フルロードマイグレーション中は、ターゲットテーブルの外部キー制約をオフにします。
レプリケーションの CDC フェーズを開始する前に、ターゲットデータベースにセカンダリインデックスを追加します。
Amazon RDS プライマリユーザーには、デフォルトのスキーマテーブルに対する削除および再作成の権限がありません。そのため、AWS DMS を使用してソースからデフォルトのデータベースまたはスキーマテーブルを移行することは避けてください。
AWS DMS で正常に移行できるデータのタイプについては、「AWS DMS を使用した MySQL から MySQL へのデータの移行」のドキュメントを参照してください。
バッチ適用 CDC メソッドを使用する前に、デフォルトのトランザクション CDC 適用を使用してワークロードをテストします。詳細については、「DMS バッチ適用機能を使用して CDC レプリケーションパフォーマンスを向上させるにはどうすればよいですか?」を参照してください。
本番環境の移行を開始する前に、他の QA/DEV データベース環境で同じ本番データを使用して移行をテストします。本番環境の移行を行う場合は、必ず同じ AWS DMS 設定を使用してください。

詳細については、「AWS DMS 移行のパフォーマンスの向上」を参照してください。

ソースデータベースとターゲットデータベースで推奨される設定と方法を使用する

1.ターゲット MySQL/PostgreSQL データベースにテーブル DDL を手動で事前に作成します。次に、ターゲット準備モードを DO_DOTHING"/"TRUNCATE に設定して AWS DMS タスクを作成し、データのみを移行します。

次のコマンドを実行して、ソース MySQL データベースのデータを含まないダンプを作成します。

mysqldump -h yourhostnameorIP -u root -p --no-data --skip-triggers --single-transaction --dbname > schema.sql

このコマンドは、データなしでソースから DDL 構造をダンプします。

次に、次のコマンドを実行して、ターゲットに DDL 構造を復元します。

mysql -u user -p -h yourhostnameorIP  database_name < schema.sql

または、DROP AND CREATE ターゲット準備モードを使用して、AWS DMS がターゲットにテーブルを作成できるようにすることもできます。次に、CDC フェーズのタスクを再開する前に、ステップ 3 に進んでテーブルを変更し、セカンダリインデックスなどの不足しているオブジェクトを追加します。

注: デフォルトでは、AWS DMS はプライマリキーまたは一意のキーのみを使用してターゲットにテーブルを作成します。他のオブジェクトはターゲット MySQL データベースに移行されません。

2.フルロード中、AWS DMS は外部キーリレーショナルテーブルを識別しません。データはランダムにロードされるため、ターゲットデータベースで外部キーチェックがオンになっていると、テーブルのロードが失敗することがあります。ターゲット MySQL エンドポイントで次の追加の接続属性 (ECA) を使用して、この AWS DMS セッションの外部キーチェックをオフにします。

initstmt=SET FOREIGN_KEY_CHECKS=0;

詳細については、「AWS DMS のターゲットとして MySQL 互換データベースを使用する場合の追加の接続属性」を参照してください。

3.JSON 設定で、キャッシュされた変更を適用する前のタスク停止を true に設定し、キャッシュされた変更を適用した後のタスク停止を true に設定します。

"FullLoadSettings": {
    "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD"
    "CreatePkAfterFullLoad": false,
    "TransactionConsistencyTimeout": 600,
    "MaxFullLoadSubTasks": 8,
    "StopTaskCachedChangesNotApplied": true,   <--- set this to true
    "StopTaskCachedChangesApplied": true,    <--- set this to true
    "CommitRate": 50000,
}

フルロードが完了し、キャッシュされた変更を適用する前に、タスクは停止します。タスクが停止している間に、ターゲットにプライマリキーインデックスとセカンダリインデックスを作成します。

次に、キャッシュされた変更を適用した後にタスクが再び停止するので、タスクを再開します。次に、CDC レプリケーションフェーズのタスクを再開する前に、AWS DMS 検証出力または手動検証を使用して移行されたデータを検証します。このステップを完了すると、CDC のレプリケーションを再開する前に、問題があれば特定して対処できます。

4. タスクのフルロード設定で、commitRate 設定を調整して、ソースからのデータ抽出を高速化します。デフォルト値は 10000 なので、ソーステーブルから大量のデータを移行する場合は、この設定を調整します。

CommitRate=50000

注: commitRate の値を高くするとパフォーマンスに影響する可能性があるため、レプリケーションインスタンスをモニタリングし、十分なメモリを確保してください。

5. この ECA をターゲットエンドポイントに追加して、ターゲット MySQL にデータを転送するために使用される任意の .csv ファイルの最大サイズ (KB) を指定します。デフォルト値は 32,768 KB (32 MB) で、有効な値の範囲は 1～1,048,576 KB (最大 1.1 GB) です。

maxFileSize=250000;

注: MySQL、Aurora、または MariaDB などのターゲットインスタンスをフルロードに使用する場合は、このオプションを使用して、AWS DMS がバックグラウンドで .csv ファイルを作成し、ターゲットインスタンスにデータをロードできるようにします。32 MB から 1 GB の間の値を使用します。ただし、ターゲットインスタンスがどれだけ処理できるかも考慮してください。1 GB の .csv ファイルをロードする複数のタスクがある場合、ターゲットインスタンスにオーバーヘッドが発生する可能性があります。ターゲットに高いコンピューティング能力を持つインスタンスがあることを確認してください。

6. パフォーマンスを向上させるには、制限付き LOB またはインライン LOB 設定を使用します。

制限付き LOB モード: 制限付き LOB モードを使用する場合は、LOB 列データの最大サイズを指定します。これにより、AWS DMS はリソースを事前に割り当て、LOB を一括で適用できるようになります。LOB 列のサイズがタスクで指定したサイズを超える場合、AWS DMS はデータを切り捨てます。その場合、AWS DMS は AWS DMS ログファイルに警告を送信します。制限付き LOB モードを使用するとパフォーマンスは向上しますが、タスクを実行する前に、ソース上のデータの最大 LOB サイズを特定する必要があります。次に、[Max LOB size] (最大 LOB サイズ) パラメータを指定します。タスクを処理するのに十分なメモリがレプリケーションインスタンスに割り当てられていることを確認することをお勧めします。

インライン LOB モード: インライン LOB モードを使用する場合、小規模および大規模な LOB の両方をレプリケートすることで、データを切り捨てたり、タスクのパフォーマンスを低下させたりすることなく、LOB を移行できます。まず、InlineLobMaxSize パラメータの値を指定します。これは、Full LOB モードが true に設定されている場合にのみ使用できます。AWS DMS タスクは小規模の LOB をインラインで転送するため、効率的です。次に、AWS DMS は、ソーステーブルからルックアップを実行して、Full LOB モードで指定されたサイズを超える LOB を移行します。ただし、インライン LOB モードは、フルロードフェーズでのみ機能することに注意してください。

注: タスクのタスク設定を指定するときに InlineLobMaxSize を設定する必要があります。

以下のクエリを実行して LOB サイズを確認し、[最大 LOB サイズ] に入力します。

次のクエリで、LOB 列を持つテーブルを一覧表示します。

select tab.table_name,
count(*) as columns
from information_schema.tables as tab
inner join information_schema.columns as col
on col.table_schema = tab.table_schema
and col.table_name = tab.table_name
and col.data_type in ('blob', 'mediumblob', 'longblob',
'text', 'mediumtext', 'longtext')
where tab.table_schema = 'your database name'.  <---- enter database name here
and tab.table_type = 'BASE TABLE'
group by tab.table_name
order by tab.table_name;

次のクエリで、LOB 列のサイズを確認します。

Select (max(length (<COL_NAME>))/(1024)) as “size in KB” from <TABLE_NAME>;

すべてのテーブルの LOB 列のサイズを確認し、[最大 LOB サイズ (K)] に最大サイズを入力します。

63 KB を超える値で [Max LOB size (K)] (最大 LOB サイズ (K)) オプションを使用すると、制限付き LOB モードで実行するように設定されたフルロードのパフォーマンスに影響します。フルロード中、AWS DMS は [Max LOB size (K)] (最大 LOB サイズ (K)) の値とコミットレートの積でメモリを割り当てます。次に、積に LOB 列の数が乗算されます。

AWS DMS がそのメモリを事前に割り当てることができない場合、AWS DMS は SWAP メモリを消費し始めます。これはフルロードのパフォーマンスに影響します。そのため、制限付き LOB モードの使用時にパフォーマンスの問題が発生した場合は、許容できるレベルのパフォーマンスが達成されるまでコミットレートを下げます。または、テーブルの LOB 分散をまず確認した後、サポートされているエンドポイントにインライン LOB モードを使用することを検討してください。

詳細については、「AWS DMS タスクのソースデータベースの LOB サポートの設定」を参照してください。