EC2上のMySQLをRDSに移行する際のポイントとか

Amazon RDSとは、Amazonが提供するマネージドのMySQLサービス（OracleとMicrosoft SQL Serverもあるけど）。

最近、いくつかのプロジェクトでEC2上のMySQLからRDSに移行したので、その際に気をつけるポイントとかを書いてみる。

RDSの制約

メンテナンスウィンドウ

セキュリティパッチの適用などが、事前に設定したメンテナンスウィンドウの中で行われる。例えば、メンテナンスウィンドウを月曜の1:00〜1:30に設定した場合、この時間帯でメンテナンスが行われる「可能性がある」。毎週この時間帯でメンテナンスが必ず行われるわけではないってのはFAQ。

ちなみに、通常はメンテナンスに伴いサーバー再起動等のサービス断が発生するが、それに関して事前に通知などはないので、RDSにつながらない場合はエラー画面を出すなどの仕組みをアプリ側で用意する必要がある。

（実質）InnoDB以外は使えない

RDSは実質InnoDBしか使えない。MyISAMもとか使えるけど、スナップショットからのリカバリーにコケる可能性があるらしい。詳しくはドキュメントを参照。

自分が関わった範囲だとmroongaを使っていたDBをRDSに移行する例があったが、その場合はそのまま移行できない。全文検索を別で構築し、当該テーブルをInnoDBに変換してから移行をした。

root権限が無いので出来ないことがある

managedサービスなんで当たり前だけど、設定変更できないパラメータとかがあるので、事前に調べておくことをオススメする。

TimezoneはUTC固定

海外展開を考えている人、国内以外のレンタルサーバー等を使った事ある人なら、タイムゾーンをAsia/TokyoにするよりUTCにしておいて、表示する時にプログラム側で適切なタイムゾーンに変換した方が楽ってのは知っているだろうし既にそうしていると思うが、もし現在のDBサーバーのタイムゾーンをAsia/Tokyoにしている場合には、事前に設定変更・プログラム修正で対応しておく必要がある。

構築関連

これは移行とはあまり関係ないけど、AWSに慣れていない人にとって1点だけ分かりにくい点があったので念のため書いておく。

構築時にセキュリティグループの設定を行うが、これはドキュメントを読めば書いてあるんだけど、指定したセキュリティグループを持つEC2インスタンスからの接続を許可する、という意味なので注意が必要。

データ移行

ようやく本題。

手段

EC2上のMySQLとRDS間でレプリケーションを設定する事は出来ないので（※）、mysqldump コマンドでエクスポートしてそれをRDSにインポートするというのが一般的と思われる。

AWS上で一応こんなドキュメントがあるので、軽く目を通しておくといいかも。特に目新しいことは書いてないけど。

※今までは出来なかったんだけど、最近、外部MySQL <-> RDSのレプリケーションが出来るようになったらしい。こちらのブログ記事とそのコメント欄を参照。

インポート時の設定

mysqldump の結果をRDSにインポートする際、大きなテーブルのインポートで以下のようなエラーが出る場合がある。

```
ERROR 2006 (HY000) at line 4083: MySQL server has gone away
```

しばらく無通信の時に起きるエラー。対応策として、RDSのパラメータグループで、 max_allowed_packet を増やしたら解決した。自分の場合、デフォルトの 1048576 から 33554432 に変更。

移行後

実行計画が変わった

いくつかのクエリーが移行前後で実行計画が変わった。この辺のパラメータが違っていた可能性がある（今は確かめられないけど）。

自分達が取った対応は、STRAIGHT JOINを使うという方法だったんだけど、上述のパラメータを移行前のものにあわせれば解消するかも。

他にも何かあったきが

ちょっと今は思い出せないけど、何かあった気が。思い出したら追記予定。

まとめ

移行って面倒すね。

MySQLの管理に時間を余り取られたくない人、あまり大規模なサービスになる（orする）予定が無い場合とかは、こうしたmanagedサービスの方が楽だし、最初からRDSを使用したほうが良いと思う。

細かいカスタマイズが必要な場合などは、自前で立てたほうが良い。

という一般的な結論で本記事は終わりにします。間違ってる点などがありましたら、ご指摘頂けると幸いです。