エキサイト株式会社の武藤です。
以前VPCのサイジングに失敗し、VPCを再構築したお話を紹介しました。 VPC再構築判断の結果、既にAWSで本番稼働していたDBも移行することになりました。 tech.excite.co.jp
DBをAWSに移行した際に、DMSを使った事例も以前に紹介しています。 tech.excite.co.jp
DMS利用の流れについて大筋は以前と変わりませんので、今回は移行元がAuroraである場合のポイントについて紹介します。 前提として今回のDB移行では、Aurora 2 (MySQL 5.7) から Aurora 2 に移行しました。
VPC間のアクセス設定
VPCからVPCへマイグレーションを行うので、VPCピアリングを設定し、通信できるようにします。
また、DMSの実行はレプリケーションインスタンスで行います。 移行先のVPCにレプリケーションインスタンスを作った場合、レプリケーションインスタンスから移行元DBへ接続します。 そのため、移行元DBのセキュリティグループのインバウンドルールに許可設定も必要です。
バイナリログの設定
DMSのマイグレーションはCDC(変更データキャプチャ)形式で行います。 MySQLの場合バイナリログの有効化が必要なので、その手順について説明します。
保持期間の変更
Auroraのバイナリログは、デフォルトで保持期間が設定されていません。 そのため、バイナリログは可能な限り早く削除されてしまいます。 DMSでバイナリログを読み取るために保持期間を設定します。
移行元のAuroraにログインして、下記のようにコマンドを実行します。
CALL mysql.rds_set_configuration('binlog retention hours', 144);
保持期間は144時間 (6日間)としました。十分な期間であれば変えても問題ないと思います。
パラメータグループの変更
バイナリログを有効にするため、移行元DBのパラメータグループを下記のように修正します。
- binlog_format: ROW
- binlog_checksum: NONE
- binlog_row_image: FULL
パラメータグループの修正後、設定を反映させるために再起動を行います。 ライターインスタンスの再起動が必要になるため、サービスに影響が出ないようメンテナンス等の対応を検討します。
DMSのソースエンドポイントの設定
最後に、DMSのソースエンドポイントの設定です。 Auroraのライターインスタンスをソースに設定します。リーダーインスタンスはソースエンドポイントに設定できませんでした。
まとめ
Aurora を移行元としたDMSの設定について紹介しました。 バイナリログの有効化についていくつか設定が必要です。 ご参考になれば幸いです。
