AWS Database Migration Serviceはデータベースの移行支援サービスです。
今回は、オンプレミスで稼働するMySQLからAWS上のAmazon Aurora MySQLに移行した際に利用しました。
MySQLのバージョンに制約があります。今回は条件を満たしていなかったのでオンプレミスのMySQLバージョンアップを行い利用可能にしました。
MySQL バージョン 5.5、5.6、5.7、8.0
MySQL 互換データベースの AWS DMS のソースとしての使用 - AWS Database Migration Service
Black Belt Online
必要なもの
データを移行する際は、データ移行タスクを作成することになりますがその中で下記リソースが必要になるので事前に作成が必要です。
- レプリケーションインスタンス
- ソースデータベースエンドポイント
- ターゲットデータベースエンドポイント
また、レプリケーションインスタンスはサブネットグループに配置します。
デフォルトでも用意されていますが必要であればサブネットグループも事前に作成が必要です。
レプリケーションインスタンス
レプリケーションインスタンスは、ソースデータベースから移行対象のデータを取得してターゲットデータベースのエンジンに合わせてデータを変換してからターゲットデータベースにデータを流します。
レプリケーションインスタンスを作成する際は、インスタンスクラスを設定することになりますが移行対象のデータ量によって要求スペックがかなり変わってきます。
レプリケーションインスタンスのモニタリングをしつつ、必要であればインスタンスタイプを上げるなどの対応が必要になります。
また、複数のデータ移行タスクを1つのレプリケーションインスタンスで行うことも可能です。
ソース、ターゲットデータベースエンドポイント
名前の通り移行元及び移行先のデータベースの情報を設定します。
また、エンドポイントでは追加の接続設定が可能です。主にタイムゾーンの問題で利用する機会がありました。後述します。
データベース移行タスク
データベース移行タスクでは、前述のレプリケーションインスタンス、ソースデータベースエンドポイント、ターゲットデータベースエンドポイントを指定した上で移行タイプについて設定していきます。
移行タイプ
- 既存のデータを移行する
- 既存のデータを移行して、継続的な変更をレプリケートする
- データ変更のみをレプリケートする
上記は、マネジメントコンソール上の日本語表記になりますが
- 「既存のデータを移行する」->「Full load」
- 「変更をレプリケート」->「CDC」(Change Data Capture)
英語表記の方が使いやすいのでそちらで呼称していましたし、以後の記載もそうします。
- Full load
- Full load + CDC
- CDC
タイムゾーン問題
移行タイプ決定の際にタイムゾーンの問題があり選択肢が限定されたのでまずその事象を記載します。
前提
| データベース | ソース | ターゲット |
|---|---|---|
| タイムゾーン | Asia/Tokyo | Asia/Tokyo |
結果
ターゲットにUTCの時刻が登録されてしまう(9時間前の時間)
Stack Overflowを参考にFull loadの場合以下設定で解決しました。
ソースエンドポイント追加属性
serverTimezone=Asia/Tokyo;
ターゲットエンドポイント追加属性
initstmt=SET time_zone='Asia/Tokyo'
ただCDCの場合これでは解決しません。
AWS DMS（Data Migration Service）の CDC（Change Data Capture）で MySQL（RDS / Aurora MySQL を含む）から MySQL（同）にデータをレプリケーションで移行するときは、 ソースエンドポイントのタイムゾーンを設定しない
小ネタ／AWS DMS（CDC）で MySQL to MySQL 移行時のタイムゾーン指定
感謝。つまりCDCの場合は下記のみ設定する必要があります。
ターゲットエンドポイント追加属性
initstmt=SET time_zone='Asia/Tokyo'
以上のことからFull loadとCDCで別のエンドポイントを使用しなければならず、データベース移行タスクも必然的に分けることになるのでFull load+CDCは使用できないという結果になりました。
Full load 移行タスク
Full loadは、既存のデータを移行してくれるものでMySQLでいうとmysqldumpをrestoreすることに近いです。
ただ、Full loadにもかなり注意しなければならない点があり最終的には不採用になりました。
1番影響が大きかったのは下記のセカンダリインデックスが作成されない点です。
ただし、AWS DMS では、ターゲットデータベースのセカンダリインデックス、外部キー、ユーザーアカウントなどは自動的に作成されません。
AWS Database Migration Service のベストプラクティス - AWS Database Migration Service
当然のことながらデータベースを運用する中で、複数のテーブルで様々なインデックスを作成しておりますが
それが移行されないのはかなり苦しく初期データに関してはFull loadを利用せずmysqldumpをrestoreする形で移行することにしました。
CDC 移行タスク
CDCは、データの変更があった際にその変更をターゲット側にも適応してくれるもので所謂レプリケーションです。
バイナリログファイルの位置ベースのレプリケーションで利用しているバイナリログをDMSで利用することで実現するので、ソースデータベースの設定ファイルに設定が必要です。
| server-id | レプリケーショントポロジ内で一意な自然数 |
|---|---|
| log-bin | バイナリログファイル名 |
| binlog_format | ROW |
| expire_logs_days | 1以上 |
| binlog_checksum | NONE |
| binlog_row_image | FULL |
| log_slave_updates | レプリカをソースにしたい場合はTRUE |
log_slave_updatesについては、オンプレミスでのレプリケーションでのレプリカでDMSとレプリケーションしたほうがオンプレミスへの影響が少ないので今回は有効にしてやりました。
あとは、CDC開始ポイントをオンプレミスのレプリカから取得して設定すればCDCに関する設定は完了です。
テーブルマッピングによりCDC対象のスキーマとテーブルを絞ることができます。ここでは割愛します。
まとめ
全体的に気にしなければならないことが多いのですが、それでもマネジメントコンソール上でCDCのON/OFFが簡単に切り替えられたり、
網羅的に状況を見れるという点では使ってよかったです。
