Aurora MySQLを別のAWSアカウントへ移すときは、データをどの時点で確定させ、切替までの更新差分をどう扱うかを先に決めます。スナップショット共有、クロスアカウントクローン、AWS DMSは、それぞれ得意な場面が異なります。
停止できる時間から方式を選ぶ
| 方式 | 向いている場面 | 注意点 |
|---|---|---|
| 手動スナップショット共有・復元 | 取得時点のデータから移行先を作りたい | 取得後の更新は自動で追従しない |
| クロスアカウントクローン | 対応条件内で素早く複製を作りたい | 継続レプリケーションではない。暗号化などの制約を確認する |
| AWS DMSのフルロード＋CDC | 稼働中に転送し、切替時の停止を短くしたい | ログ設定・ネットワーク・移行対象の検証が必要 |
ここではAurora MySQLを対象に整理します。方式を決める前に、エンジンバージョン、リージョン、暗号化キー、データ量、許容停止時間を確認してください。
スナップショット共有：手順を整理しやすい方法
移行元で手動DBクラスタースナップショットを取得し、移行先アカウントへ共有して復元します。自動スナップショットを共有したい場合は、コピーして手動スナップショットを作成します。共有対象は移行先アカウントに限定します。スナップショット共有の公式手順を参照してください。
単純なスナップショット方式でデータ欠落なく切り替えるなら、最終スナップショット取得前に書き込みを止め、復元と確認が終わるまで更新を再開しない計画が必要です。事前に復元時間を測り、接続先変更や業務確認の時間も停止時間に含めます。
暗号化されている場合はKMSキーを先に確認
デフォルトのAWS KMSキーで暗号化されたスナップショットは、そのまま共有できません。カスタマー管理キーを指定したコピーを作成し、スナップショットの共有に加えてキーの利用許可を設定します。共有設定だけを終えても、移行先がキーを利用できなければ復元できません。暗号化スナップショットの共有で必要な設定を確認します。
クロスアカウントクローン：作成後の更新は追従しない
AWS RAMを使うと、別アカウントにAuroraクラスターのクローンを作成する許可を共有できます。スナップショットを取得して復元するより速く複製を作れることが利点です。
ただし、クローンを作った後の移行元の更新が、そのままクローンへ流れ続けるわけではありません。作成が速いことと、無停止で移行できることは別です。業務切替に使う場合は、複製対象のデータを確定する時点と書き込み停止を計画します。
デフォルトのRDSキーで暗号化されたクラスターはクロスアカウントクローンを作成できません。暗号化キーの共有、対応するリージョン・エンジン条件、作成可能なクローン数なども事前確認が必要です。アカウント間クローンの制約とAuroraクローンの仕組みを併せて参照してください。
AWS DMS：更新差分を追従させて停止を短くする
AWS DMSのフルロードとCDCを組み合わせると、既存データを転送した後も変更を移行先へ反映できます。切替前に大部分のデータを転送できる一方、移行元・移行先への接続、DBユーザーの権限、ログ保持、タスク設定などを準備する必要があります。
Aurora MySQLをソースにしてCDCを使う場合は、バイナリログの有効化や形式、保持時間を確認します。必要な設定はバージョンによって異なるため、MySQL互換ソースの前提条件を使用環境に合わせて確認してください。
DMSのタスクが成功しても、ユーザー権限やすべてのスキーマオブジェクト、周辺設定まで同一になったとは限りません。対象範囲と整合性を確認し、DMSの移行計画・検証の指針に沿ってリハーサルします。「DMSなら停止時間は必ずゼロ」とは見積もらないことが重要です。
本番切替で共通して確認すること
- 移行先のネットワーク、パラメータ、監視、バックアップ、接続情報を準備する。
- 選んだ方式でデータを移し、代表的なクエリとアプリケーション動作を確認する。
- 切替時に移行元への書き込みを止める。
- DMSなら未反映の差分やエラーを確認する。スナップショット・クローンなら停止後の確定データを使う手順を実施する。
- 接続先を新しいクラスターへ変更し、読み書きと業務結果を確認する。
- 新環境の更新が始まった後の切り戻し方法を確認してから、旧環境を整理する。
新環境に書き込んだ後は、接続先を旧環境へ戻すだけではその更新が引き継がれません。戻す条件と差分の扱いを、移行方式と一緒に決めておきましょう。
