サーバサイドエンジニアの178inaba(@178inaba_)です。
先日、弊社サービスでありましたPairyを株式会社リンクバル様に譲渡致しました。

今回はMySQLをリンクバル社のRDSに移行する際に使用した「AWS Database Migration Service」の使い方について書こうと思います。

AWS Database Migration Serviceとは

その名の通り、データベース移行用のSaaSです。
様々なDBに対応しており、移行時のデータ加工も可能です。

今回の要件

別のAWSアカウントのRDSに移行
MySQL 5.6からMySQL 5.6への移行
ターゲットのRDSがあるAWSアカウントでDMSを動かす
スキーマ変更無し

手順

ソース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コンソールのパラメータグループで設定します。

f:id:i178inaba:20181214182422p:plain

スキーマの移行

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の設定

リソースを個々に設定することもできますが今回はウィザードを使いました。

今すぐ始めるをクリック

f:id:i178inaba:20181214162739p:plain

次へをクリック

f:id:i178inaba:20181214163301p:plain

レプリケーション インスタンスの設定

名前と説明を記述。
インスタンスクラスを選ぶ。
- 今回の移行では dms.t2.small だとレプリケーションがエラーになりました。
  なので dms.t2.medium 以上が望ましいです。
VPCをターゲットRDSインスタンスと同じにする。
パブリックアクセス可能にチェック。

f:id:i178inaba:20190425204404p:plain

アドバンスト を開き、セキュリティグループの設定をする。
- ターゲットのRDSインスタンスと同じセキュリティグループにします。

f:id:i178inaba:20181214170426p:plain

次へをクリック

f:id:i178inaba:20181214170854p:plain

エンドポイントの設定

ソースRDSとターゲットRDSのエンドポイント設定をします。

セキュリティグループでアクセスを許可する

まず、レプリケーションインスタンスのIPを調べます。
別タブでレプリケーション一覧を開き、対象DMSインスタンスのIPを確認します。

f:id:i178inaba:20181214175751p:plain

ソースRDS

DMSインスタンスのIPアドレスをソースRDSのセキュリティグループで許可します。

f:id:i178inaba:20181214180129p:plain

ターゲットDB

レプリケーションインスタンスを作成した際にターゲットRDSインスタンスと同じセキュリティグループを設定したのでセキュリティグループの設定で今編集しているセキュリティグループ自身を許可します。

f:id:i178inaba:20181214181901p:plain

Database Migration Service側のエンドポイント設定

レプリケーションインスタンスからDBインスタンスに接続する設定を行います。

ソース

f:id:i178inaba:20181214183539p:plain

ターゲット

f:id:i178inaba:20190425205022p:plain

タスクの作成

レプリケーションタスクの設定を行います。
今回は設定から移行当日までレプリケーションし続けるため移行タイプを「既存のデータを移行して、継続的な変更をレプリケートする」にします。

f:id:i178inaba:20181214184255p:plain

タスク設定セクションは正しくレプリケーションできているかを確認するため「検証の有効化」とエラーがあった場合の調査のため「ロギングの有効化」を有効にします。

f:id:i178inaba:20181214184924p:plain

選択ルールでは移行するスキーマを選択し、テーブル名はワイルドカードの「%」、アクションは「含める」を設定します。これで対象スキーマのすべてのテーブルが移行されます。

f:id:i178inaba:20181214185459p:plain

最後にタスクの作成ボタンをクリック

f:id:i178inaba:20181214185506p:plain

タスクの開始

基本的にはタスクの作成時に「作成時にタスクを開始」にチェックを入れておけば自動で開始されるはずですが、開始されない場合はタスク一覧の「開始/再開」ボタンをクリックすると開始されます。

f:id:i178inaba:20181214190252p:plain

まとめ

AWS Database Migration Serviceを使用して事前にSyncしておくことで簡単に移行当日の作業を減らすことができました。
Database Migration ServiceはMySQLからAurora等の移行もスムーズに行えるためレガシーなDBを使っていて移行を考えている方は一度検討してみてはいかがでしょうか。