サーバサイドエンジニアの178inaba(@178inaba_)です。
先日、弊社サービスでありましたPairyを株式会社リンクバル様に譲渡致しました。
今回はMySQLをリンクバル社のRDSに移行する際に使用した「AWS Database Migration Service」の使い方について書こうと思います。
AWS Database Migration Serviceとは
その名の通り、データベース移行用のSaaSです。
様々なDBに対応しており、移行時のデータ加工も可能です。
今回の要件
手順
ソースDBの設定
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.MySQL.html#CHAP_Source.MySQL.AmazonManageddocs.aws.amazon.com
上記に記述されている設定を行います。
今回必要だったのは下記の3つの設定でした。
- 次のコマンドをMySQLコンソールで実行
call mysql.rds_set_configuration('binlog retention hours', 24);
- binlog_formatパラメータを「ROW」に設定
- binlog_checksum パラメータを「NONE」に設定
パラメータはRDSコンソールのパラメータグループで設定します。
スキーマの移行
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.MySQL.html#CHAP_Source.MySQL.Limitationsdocs.aws.amazon.com
列の AUTO_INCREMENT 属性は、ターゲットデータベース列に移行されません。
とあるように、DMSではAUTO_INCREMENTの値は移行されないため、事前にソースDBのスキーマを取得して、ターゲットDBにスキーマのみ作成しておく必要があります。
スキーマさえ移行すればAUTO_INCREMENTの値も移行されます。
今回は取得したスキーマファイルをS3を介してやりとりしました。
ソースDBのスキーマの取得
# スキーマの取得 $ mysqldump -h <RDSのエンドポイント> -u <ユーザ名> -p<パスワード> --single-transaction --no-data <DB名> > ddl.sql # S3にアップロード(別アカウントのS3にアップロードするためaclに `bucket-owner-full-control` を使用) $ aws s3 cp ddl.sql s3://<バケット名>/ddl.sql --acl bucket-owner-full-control
ターゲットDBのスキーマ流し込み
DBを作成し、スキーマを流し込みます。
# スキーマファイルをS3から取得 $ aws s3 cp s3://<バケット名>/ddl.sql ddl.sql # DBの作成 $ mysql -h <RDSのエンドポイント> -u <ユーザ名> -p<パスワード> > DROP DATABASE `<DB名>`; > CREATE DATABASE `<DB名>`; # スキーマを流し込む $ mysql -h <RDSのエンドポイント> -u <ユーザ名> -p<パスワード> <DB名> < ddl.sql
AWS Database Migration Serviceの設定
リソースを個々に設定することもできますが今回はウィザードを使いました。
今すぐ始めるをクリック
次へをクリック
レプリケーションインスタンスの設定
- 名前と説明を記述。
- インスタンスクラスを選ぶ。
- 今回の移行では
dms.t2.smallだとレプリケーションがエラーになりました。
なのでdms.t2.medium以上が望ましいです。
- 今回の移行では
- VPCをターゲットRDSインスタンスと同じにする。
- パブリックアクセス可能にチェック。
- アドバンスト を開き、セキュリティグループの設定をする。
- ターゲットのRDSインスタンスと同じセキュリティグループにします。
- 次へをクリック
エンドポイントの設定
ソースRDSとターゲットRDSのエンドポイント設定をします。
セキュリティグループでアクセスを許可する
まず、レプリケーションインスタンスのIPを調べます。
別タブでレプリケーション一覧を開き、対象DMSインスタンスのIPを確認します。
ソースRDS
DMSインスタンスのIPアドレスをソースRDSのセキュリティグループで許可します。
ターゲットDB
レプリケーションインスタンスを作成した際にターゲットRDSインスタンスと同じセキュリティグループを設定したのでセキュリティグループの設定で今編集しているセキュリティグループ自身を許可します。
Database Migration Service側のエンドポイント設定
レプリケーションインスタンスからDBインスタンスに接続する設定を行います。
ソース
ターゲット
タスクの作成
レプリケーションタスクの設定を行います。
今回は設定から移行当日までレプリケーションし続けるため移行タイプを「既存のデータを移行して、継続的な変更をレプリケートする」にします。
タスク設定セクションは正しくレプリケーションできているかを確認するため「検証の有効化」とエラーがあった場合の調査のため「ロギングの有効化」を有効にします。
選択ルールでは移行するスキーマを選択し、テーブル名はワイルドカードの「%」、アクションは「含める」を設定します。 これで対象スキーマのすべてのテーブルが移行されます。
最後にタスクの作成ボタンをクリック
タスクの開始
基本的にはタスクの作成時に「作成時にタスクを開始」にチェックを入れておけば自動で開始されるはずですが、開始されない場合はタスク一覧の「開始/再開」ボタンをクリックすると開始されます。
まとめ
AWS Database Migration Serviceを使用して事前にSyncしておくことで簡単に移行当日の作業を減らすことができました。
Database Migration ServiceはMySQLからAurora等の移行もスムーズに行えるためレガシーなDBを使っていて移行を考えている方は一度検討してみてはいかがでしょうか。
積極採用中！！
子育て家族アプリFammを運営するTimers inc.では、現在エンジニアを積極採用中！
急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください！
採用HP: http://timers-inc.com/engineerings
