こんにちは、ちゃりおです。
Aurora移行を検証してみました。
Aurora移行の方法としては、RDSでAuroraリードレプリカを作ってそれを昇格させる方法がメジャーだと思います。
(サポートに聞いて、最初に勧められる手順だと思います。)
Aurora リードレプリカを使用した、MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行
リードレプリカを利用する方法は手間は少ないですが、リードレプリカを昇格させる際に１０分ほどダウンタイムが発生します。
ダウンタイムを極力少なくしたいという要件があったため、今回はDMSを使用しました。
本記事を通してDMSで移行する場合の、流れをざっくり把握してもらえればと思います。
Auroraに移行するメリット
いろいろな記事でメリットについて、紹介されているので本記事では触れません。
Amazon Auroraの良さについてまとめてみた
Auroraの凄さを振り返る
DMSとは
データベースを移行するAWSのサービスです。
DMSを使うことで、移行元DBと移行先DBでレプリケーションをはることができます。
AWS Database Migration Service
DMSでAurora移行
Auroraインスタンス作成
Auroraインスタンスを作成します。
インスタンス作成前に、下記を作りましょう。
- サブネットグループ
- オプショングループ
- パラメータグループ(クラスター・インスタンス)
接続確認・DBの作成
Auroraインスタンスを作成した状態では、空っぽの状態なのでもろもろ追加していきます。
作成したAuroraに接続します。
ユーザ名パスワードは、Auroraインスタンス作成時に設定したものを指定します。
エンドポイントは、マネジメントコンソールから確認できます。
mysql -u <ユーザ名> -h <移行先DBエンドポイント> -p;
DBを作成します。
create database <db名>;
Mysql Dump取得・スキーマ作成
スキーマを作成します。
DMSで直接作成もできるのですが、AutoIncrementの設定などが消えてしまうので手動で作成します。
既存のDBからDumpを取得します。
データはDMSで移行するので、–no-dataオプションでスキーマだけ取得しています。
mysqldump -u <ユーザ名> -h <移行元DBエンドポイント> -p --no-data <DB名> > /tmp/schema_`date "+%Y%m%d"`.sql
取得したDumpを移行先のAuroraに反映します。
mysql -u <ユーザ名> -h <移行先DBエンドポイント> -p -D <DB名> < /tmp/schema_`date "+%Y%m%d"`.sql
スキーマが移行先DBで反映されているか確認しておきます。
DBに接続して下記コマンドを実行します。
SHOW FULL COLUMNS FROM <テーブル名>;
DMSインスタンス作成
DMSインスタンスを作成します。
あまりスペックが低すぎるとタスク実行時にエラー(メモリが足りない)がでるので
インスタンスサイズは注意しましょう。
DMSエンドポイント作成
移行先と移行元のエンドポイントを作成します。
DBひとつあたり、２つ(移行先と移行元)のエンドポイントが必要です。
接続テストができるので、接続できることを確認しておきましょう。
移行元DBの「binlog_format」を「ROW」に変更
移行元DBの「binlog_format」が「ROW」タスク実行時にエラーがでるので変更しておきます。
ParameterGroupから変更可能です。
適用タイプが「Dynamic」なので、再起動不要で即時反映されます。
タスク作成・実行
ここでレプリケーションはれます。
スキーマはすでに作成しているので、「ターゲットテーブル作成モード」を「何もしない」にしておきます。
タスクを実行するとレプリケーションをはれるのですが、一度に全部はるとメモリ足りなくなる可能性もあるので
リソースの状況をみながら実行するといいです。
まとめ
今回は、DMSでRDSからAuroraに移行する方法を書きました。
多少手間と費用がかかってもダウンタイムを短くしたい場合や、DBひとつずつ移行した場合などに良いと思います。
