現在、運用中のサービスのデータベースの移行を行ったので、その記録と、事前に行った検証についてまとめてみます。
以前は、MySQL5.6以降であれば、ほぼダウンタイムなしでAuroraへの移行が可能でしたが、MySQL5.5でもいくつか手順を踏めばほぼダウンタイムなしで移行が行えるようになったようです。（以前は、気づかなかっただけかもしれませんが、確かスナップショットからAuroraを立ち上げるしか方法がなかったような気がします）
データベースの移行なんて、昔はかなりの大仕事だったのですが、AWSのおかげでだいぶ楽になりましたね。
まずは、移行前の構成です。インスタンスサイズやリージョンは特に関係ないので省きます。
| 名前（仮） | ロール | エンジン | アプリケーションからの参照 |
|---|---|---|---|
| MySQLマスター | マスター | MySQL5.5 | 参照中 |
| MySQLスレーブ | レプリカ | MySQL5.5 | 参照中 |
手順1 新しくレプリカを作成します。
AWSのコンソールで、MySQLマスターを選択して、リードレプリカの作成を行います。
新しく作成するレプリカは、稼働中のアプリケーションでは利用しないので、サイズは小さめで問題ありません。
逆に、新しく追加したレプリカを稼働中のアプリケーションから参照しないように注意してください。
作成後の構成
| 名前（仮） | ロール | エンジン | アプリケーションからの参照 |
|---|---|---|---|
| MySQLマスター | マスター | MySQL5.5 | 参照中 |
| MySQLスレーブ | レプリカ | MySQL5.5 | 参照中 |
| MySQLスレーブNEW | レプリカ | MySQL5.5 |
手順2 新しく作成したレプリカのMySQLを5.6にアップグレードします。
新しく作成したMySQLスレーブNEWは、アプリケーションから参照されていない状態なので、稼働中のアプリケーションに影響はないので、AWSコンソールでMySQLのバージョンを5.6にアップグレードしてしまいます。すぐに適用で問題ないかと思います。
MySQLのアップグレード後の構成
| 名前（仮） | ロール | エンジン | アプリケーションからの参照 |
|---|---|---|---|
| MySQLマスター | マスター | MySQL5.5 | 参照中 |
| MySQLスレーブ | レプリカ | MySQL5.5 | 参照中 |
| MySQLスレーブNEW | レプリカ | MySQL5.6 |
※ MySQLが5.6にアップグレードしたことによるアプリケーションへの影響は別途確認しておいてください。
手順3 Auroraリードレプリカの作成
MySQL5.6にアップグレードしたレプリカBは、Auroraリードレプリカの作成が可能になるので、AWSのコンソールで、Auroraリードレプリカの作成を行います。
Auroraのリードレプリカの作成時に設定する値は、適宜ご自身の環境に合わせたものをご検討ください。
また、Auroraでデータベースを作成時にマルチAZを選択すると、MySQLとは違って、コールドスタンバイ状態ではなく、実際に利用できるレプリカとして機能しますので、この辺も移行するためのメリットにもなっているのではないかなと思います。
Aurora リードレプリカの作成後の構成
| 名前（仮） | ロール | エンジン | アプリケーションからの参照 |
|---|---|---|---|
| MySQLマスター | マスター | MySQL5.5 | 参照中 |
| MySQLスレーブ | レプリカ | MySQL5.5 | 参照中 |
| MySQLスレーブNEW | マスター,レプリカ | MySQL5.6 | |
| Auroraマスター | 書き込み | Auroa MySQL5.6 | |
| Auroraスレーブ | 読み込み | Auroa MySQL5.6 |
手順4 アプリケーションからの参照DBの切り替え
ここまでで、新しく移行するためのAuroraの構築はできました。もちろんステータスが利用可能になっていることは確認ください。
あとは、どういったタイミングで切り替えを行うかになります。
こっからは、何度か私の方で検証したことに基づいて記載しますので、間違え等あれば、ご指摘いただけると助かります。
検証1 Auroraのリードレプリカは、構築後もレプリケーションされ続けるのか
これは、もちろん大丈夫でした。MySQLマスターに書き込まれたデータが、継続してAuroraにも反映されていました。
検証2 Auroraマスターにデータの書き込みが行えるのか
MySQLのリードレプリカの場合、書き込みが行えないのですが、Auroraのリードレプリカとして作成した、Auroraマスターには書き込みができるのか、検証してみました。結果は、書き込みが可能でした。
検証3 書き込まれた Auroraマスターのレプリケーションはどうなるのか
一度、書き込まれたAuroraマスターへのレプリケーションは、テーブル毎に停止するようです。
例えば、テーブルAにAuroraマスターから書き込みを行った場合、それ以降のデータはMySQLマスターへ書き込みされたデータが反映されない。ただし、書き込まれていないテーブルBへは、MySQLマスターへ書き込みされたデータが反映されました。
検証4 Auroraクラスターを昇格した後、レプリケーションはどうなるのか
これも、もちろんデータベース全体でレプリケーションが停止します。
以上の検証結果を元に参照DBの切り替えを行います。取りうる選択肢としては2つぐらいあるかなと思います。
A案 ほぼダウンタイムなしでの参照DBの切り替え
対象のデータベースへ参照しているアプリケーションが少ない場合など。
1.DB接続部分をAuroraに書き換えて、一気にアプリケーションをデプロイする。
2.AWSコンソールでAuroraクラスターの昇格を実行して完了
私は、なるべくアクセスが少ない時間を狙って深夜に対応しました。
B案 少しだけダウンタイムがあっても良いので慎重に切り替えたい場合
1.稼働中のアプリケーションをメンテナンス中に切り替え。もしくは書き込みのみ停止。
2.AWSコンソールでAuroraクラスターの昇格
3.アプリケーションのDB接続部分をAuroraに書き換えてデプロイ
4.アプリケーションを稼働中に戻す
DB切り替え後
| 名前（仮） | ロール | エンジン | アプリケーションからの参照 |
|---|---|---|---|
| MySQLマスター | マスター | MySQL5.5 | |
| MySQLスレーブ | レプリカ | MySQL5.5 | |
| MySQLスレーブNEW | レプリカ | MySQL5.6 | |
| Auroraマスター | 書き込み | Auroa MySQL5.6 | 参照中 |
| Auroraスレーブ | 読み込み | Auroa MySQL5.6 | 参照中 |