はじめに
EC2で運用していたMySQLをAuroraへ移行するための作業を行いました。
EC2は、Web,アプリケーションサーバーです。
作業中にさまざまな事象が発生したので、移行を検討されてる方は、ご参考にしていただければ幸いです。
1. バックアップ
移行作業前に、EBSバックアップの取得を忘れないようにしてください。
2. メンテナンスモード
EC2の停止はできないため、メンテナンスモードなどの実施を行い、アプリの利用ができないようにした方が良いです。
3. DMSの構築
移行作業を行うために、DMSインスタンスの作成を行います。
- サブネットグループの作成
- レプリケーションインスタンスの作成
- ソースエンドポイントの作成 → 作成後にエンドポイントの機能の一部である接続テストを実施
- ターゲットエンドポイントの作成 → 作成後にエンドポイントの機能の一部である接続テストを実施
※注意
ターゲットエンドポイントの設定項目より、「Initstmt=SET FOREIGN_KEY_CHECKS=0」の設定をお勧めします。
これは、外部キーの影響で、転送に失敗する可能性があるためです。
4. LOB型のカラムをNULL許容に変更
LOB型のカラムが、NOT NULLの場合、DMSを利用した移行ができない仕様となってます。
データソース元(EC2のMySQL)のLOB型のカラムをNULLに許容するための形式に変換します。
5. 空テーブルの作成
DMSにより自動的にターゲット先へテーブルは作成されますが、さまざまなエラーが発生してしまい、解決できませんでした。
移行作業の前に、ターゲット先のテーブルへ空のテーブルを作成することにしました。
この際に、DEFINERが理由で空テーブルが作成できない事象が発生したため、DEFINERを削除しました。
実行例
# 空テーブル構築ようのsqlファイルを作成
mysqldump --defaults-group-suffix=_ec2 --no-data --databases db01 --set-gtid-purged=OFF > table01.sql
# DEFINERを削除
sed -i.bak -e 's/\/\*!50013 DEFINER=`db01`@`localhost` SQL SECURITY INVOKER \*\/[ ]*//g' -e 's/\/\*!50017 DEFINER=`user01`@`localhost`\*\/[ ]*//g' table01.sql
# テーブル作成
mysql --defaults-group-suffix=_aurora < table01.sql
6. MySQLユーザーの作成
データソース元のユーザーと同じ名前,権限で、Auroraへユーザーを作成します。
7. データベース移行タスク
データベース移行タスクの作成を行った後に、下記の順番で作業します。
※注意
MySQLにデフォルトで存在する「information_schema」「performance_schema」「mysql」「sys」データベースは、対象外としてください
7.1. データベース移行評価
移行を実施する前に、テストを実施してください。
7.2. 再開
移行を開始してください。
7.3. 移行結果の確認
データベース移行タスクを実行した結果より、整合性が取れなかったり、エラーが発生するテーブルが存在したため、それらはmysqldupで移行を実施しました。
その際、hash化などしてデータソース元と、ターゲット先のテーブルの値が一致してるかどうかの検証まで行いました。
8. LOB型のカラムをNOT NULLに変更
データソース元でNULLを許容したカラムは、Aurora側では、NOT NULLになるよう変更しました。
9. DB情報の変更
バックエンドのConfigファイルや環境変数に、AuroraのDB情報に変更して、完了です。
10. ログ情報やエビデンスの保管
移行作業完了後は、DMSは削除となります。
そのため、ログや設定項目のエビデンスなど、トラブルシューティングに役立つ可能性があるため、取得しておきました。
さいごに
検証中は、ひたすらエラーとの戦いで、テーブル数が多いため体力勝負みたいなところもありました。
移行作業はとても工数がかかるタスクでしたが、DB移行のスキルが向上したので、とても良い経験ができました。