内容
AWS MGNを使用して、オンプレミス環境からAWSへ仮想マシンをリホスト方式で移行します。MGNはブロック単位で継続的にレプリケーションを行います。オンプレミスのサーバでMySQLやSQL Serverなどのデータベースが稼働している場合、静止点（データの整合性が取れた状態）を確保した上でカットオーバー処理を行う必要があります。ここでは、MGNの移行フローを踏まえ、静止点を取るべきポイントを確認します。
移行の流れ
移行ワークフローに移行の流れの記載があります。上記手順の中から移行操作とデータ同期の箇所を抜き出すと下記の様な流れになります。「ソースサーバ上の全ての運用サービスを停止」後、カットオーバー処理にて最終同期を実施して切り替えを行います。
- 初期同期の完了を待つ
- テストインスタンスを起動
- テスト完了後、テストインスタンスを終了
- ソースサーバ上の全ての運用サービスを停止
- カットオーバーインスタンスを起動
- カットオーバーの確定処理
静止点の取り方
AWS MGNには、データベースの整合性を自動で担保するようなアプリケーション整合性の制御機能はありません。そのため例として、下記の様にユーザ側でアプリケーションの状態を制御し、静止点を確保する対応が必要です。
- WEBサーバのサービス停止
- データベースサービスの停止
- ファイルI/Oを行うサービスの停止
移行の検証
移行検証を実施して、ポイントとなる箇所を見ていきます。下記はソースインスタンスにエージェントのインストールを行い、初期同期完了、テストインスタンス起動→テスト完了→テストインスタンス終了を行い、カットオーバーインスタンスの起動準備が出来た状態です。ここから最終同期処理の確認を行います。
今回、Amazon Linux上でMariaDBが稼働している環境を想定します。下記の様に静止点を取るためにMariaDBのサービスを停止します。また、自動起動を一時的に無効化しておきます。
systemctl stop mariadb
systemctl disable mariadb
また、同様のポイントで同期が行われているか簡易的に確認するために、テストファイルも作成しておきます。
touch 20250513.txt
サーバの再起動を行います。
reboot
レプリケーションステータスを確認します。「最終閲覧日」が再起動後の時間であることを確認します。
「カットオーバーインタンスの起動」を行います。
カットオーバー後のインスタンスにログイン後、MariaDBの状態が停止中であること、テスト用ファイルが存在することを確認します。
systemctl status mariadb
○ mariadb.service - MariaDB 10.5 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; preset: disabled)
ls
20250513.txt
MariaDBのサービス起動、自動起動を有効化後、「カットオーバーの最終処理」を行います。
systemctl start mariadb
systemctl enable mariadb