AWS DMSでRDS for MySQLからAurora MySQLへデータ移行してみた
はじめに
こんにちは！ヨッシーです。業務でAWSのDatabase Migration Serviceを使った大規模なデータ移行を経験したため、
アウトプットも兼ねてブログの題材にしてみました。
DMSとは
Database Migration Service(以下、DMS)は、データベースの既存データを別のデータベースへと移行するためのサービスです。また、レプリケーション機能を利用することで、本番稼働中のサービスのダウンタイムを限りなくゼロにしてデータ移行することが可能になります。
他にもオンプレミスで稼働中のデータベースからAWSのRDSへのデータベースへの移行も可能であり、
通常は工数や移行費用が莫大になったりするところを、低価格でデータ移行を実現することができます。
想定する読者
大規模なデータ移行の際に、以下のような要件がある場合は是非、DMSでのデータ移行を検討してみるべきかなと思います。- 移行による費用を安く済ませたい
- 本番稼働サービスのダウンタイムをゼロにしたい
- ダンプからリストアするような手間のかかる方法はとりたくない
- データの整合性は完全に保証したい
ドキュメント
AWS公式のDMSに関するドキュメントは以下にあります。https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.html
本記事では、こちらの内容を元に実際に手を動かしながら解説していきます。
イメージ
DMSを説明していく前に、DMS内で使われる用語の理解が必要です。DMSよる移行のイメージは公式がわかりやすいのでこちらを参照ください。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.html#Welcome.Works
メリット・デメリット
メリット
- 移行元DBの停止がない
- 移行元DBの負荷はほとんどない（検証済）
- 異なるDBエンジンへの移行が可能
デメリット
- レプリケーションを利用する場合、障害点が一つ増える
- 万能ではない（例えば、バージョンやDBによってはデータ移行できないパターンもある）
- セカンダリインデックス、非プライマリーキー制約、デフォルト値は移行できない（そのため、事前にスキーマ定義登録する必要あり）
やってみた
移行データベースの準備
移行元・移行先データベースの作成
まずは、RDSのマネージメントコンソールに入って移行元データベースと移行先データベースを作成しましょう。その際、移行元はRDS for MySQL、移行先はAurora MySQLにします。
エンジンバージョンやインスタンスクラスは自由に決めてください（料金には気をつけて）。
細かな操作方法は、記事も豊富なので説明は割愛します。
下記のように、作成されていれば完了です。
移行元のデータ準備
移行元のDBにデータベースとテーブル、レコードを作成しておきましょう。まずRDSへログインしてください。
```
$ mysql -h sourcedb-name.ap-northeast-1.rds.amazonaws.com -P 3306 -u startialab -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.7.22 Source distribution
Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
```移行で使用するデータベースを作成します。
適宜下記のコマンドのように、実行してください。
```
# データベース作成
mysql> create database dms_test_db;
# userテーブル作成
mysql> create table user (
-> id int auto_increment primary key,
-> username varchar(255),
-> email varchar(255),
-> password char(30)
-> );
# テストユーザ作成
mysql> insert into user(username,email,password) values('test01','test01@startialab.co.jp','test');
# 作成したテーブル表示
mysql> show tables;
+-----------------------+
| Tables_in_dms_test_db |
+-----------------------+
| user |
+-----------------------+
1 row in set (0.00 sec)
mysql> select * from user;
+----+----------+-------------------------+----------+
| id | username | email | password |
+----+----------+-------------------------+----------+
| 1 | test01 | test01@startialab.co.jp | test |
+----+----------+-------------------------+----------+
1 row in set (0.00 sec)
```
移行元DBのパラメータグループ設定
移行元DBがAWSのRDS for MySQLの場合は、パラメータの設定が必要です。変更するパラメータは以下の2点です。
- binlog_format パラメータを、"ROW"に設定
- binlog_checksum パラメータを、"NONE"に設定
特に、binlog_formatをROWにしておかないとDMSのタスクが失敗しますので、
タスク実行前までには設定してください。
また、こちら２つのパラメータはRDS for MySQLの場合、再起動せずとも有効化されます。
パラメータの詳細は下記の記事を参照ください。
Amazon が管理する MySQL 互換データベースの AWS DMS のソースとしての使用
それではRDSのマネージメントコンソール内のパラメータグループ設定画面へ入って、
パラメータグループの作成ボタンから以下のように、RDS for MySQL用のパラメータグループを作成してくだい。
次に、作成したパラメータグループを選択後、作成ボタンをクリックしてください。
「binlog_format」を「ROW」、「binlog_checksum」を「NONE」にしてください。
設定完了後、RDSにアタッチされているパラメータグループが同期中になっているか確認しましょう。
同期中になっていれば、パラメータの設定が反映済みです。
DMSデータ移行の準備
レプリケーションサブネットグループの作成
次に、レプリケーションインスタンスへアタッチするためのサブネットグループを作成します。サブネットグループ＞サブネットグループの追加ボタンをクリックし、下記の画像のように設定してください。
追加するサブネットは2つ以上のAZへ跨がるように追加しなければエラーになります。気をつけましょう。
レプリケーションインスタンスの作成レプリケーション＞レプリケーションインスタンスの作成ボタンをクリックして、下記のように設定を行いましょう。
レプリケーションインスタンスのインスタンスクラスは適切なものに設定してください。
また、マルチAZを有効にするのがベストプラクティスですが、今回は無効にします。
パブリックアクセスについては、同一AWSアカウント内でのDMS移行のため無効でも問題ないです。
こちらの設定項目は、オンプレのDBからの移行や、別AWSアカウントからのDB移行の際に必要な項目です。
適宜設定しましょう。
レプリケーションサブネットグループは、先程作成したものを選択しましょう。
メンテナンス設定に関してはデフォルトで問題ないです。必要に応じて設定しましょう。
設定を見直して問題なければ、作成ボタンをクリックしてください。
ステータスが「利用可能」になったら、レプリケーションインスタンスの準備完了です。
エンドポイントの作成
移行元DBと移行先DBの接続エンドポイントを作成しましょう。DMSを実行するアカウント内に移行元と移行先のDBがある場合は、
「RDS DBインスタンスの選択」をチェックし、プルダウンから該当のRDSを選択すると自動入力されます。
最後に、エンドポイント接続のテストを先程作成したレプリケーションインスタンスで実施し、
「Successful」になれば、完了です。
エラーになる場合は、セキュリティグループなどのネットワーク周りの設定やDBのログイン認証周りが問題であることが多いので、
その辺りを確認してください。
データベース移行タスクの作成
最後に、今回のDMSで実行する移行タスクを作成しましょう。今回は、データ移行後にデータ同期（継続的レプリケーション、CDC）を実施してみましょう。
移行タイプの選択で、「既存のデータを移行して、継続的な変更をレプリケートする」を選択しましょう。
移行データをフルロード後に、停止してしまわないように以下のように設定しましょう。
移行したいスキーマ、テーブルを指定できます。
任意のテーブルは移行しないなど細かく設定できます。
設定が終わると、ステータスが準備完了になります。
実行してみよう
作成した移行タスクを実行しよう。下記のように開始できます。
移行後は、継続的にレプリケーションされます。
mysqlコマンドでレコードをインサートしたり、アップデートすると移行先DBに反映されます。
まとめ
今回の記事では、DMSを使えば簡単にダウンタイムを最小にしてデータベース移行することができることがわかりました。本記事では理想的な最小構成で移行したため、ほぼ問題ありませんでしたが、
実際の移行ではデータ移行中にDMSのタスクが失敗することが多々あります。
その際の、トラブルシューティングに関しても記事に取り上げていければと思います。