【AWSシリーズ】RDSのMySQL5.5から5.6へアップグレードする手順とポイント

今年の3月にインフラチームへ移動してから早２ヶ月。 日々刺激的？な毎日を過ごしています笑 　 さて、RDSのMySQL5.6へのアップグレードをAWSが対応しました！ 今回はMySQL5.5から5.6へアップグレードする手順とメリット・デメリットを書いてみようと思います。

【背景】

業務でRDSのMySQL5.5から5.6へアップグレードするときに掛かる時間を調査する必要があった。 なので、まずはアップグレード手順の調査を行い、実際にテスト環境でアップグレードを行い、掛かる時間を算出した。

【手順】

公式ドキュメント Upgrading from MySQL 5.5 to MySQL 5.6

参考にさせて頂いたサイト
AWS新人エンジニアにおくる：RDSを5.5系から5.6系にアップグレードする方法(前半)
AWS新人エンジニアにおくる：RDSを5.5系から5.6系にアップグレードする方法(後編)
ありがとうございます！

パターンとしては二つあるかなと思っています。
①AWSで推奨しているリードレプリカを用いたパターン
②snapshotからRDSを復元し、アップグレードするパターン
それぞれのメリット、デメリットを紹介しつつ手順を書いてみます。

【注意】

2014年4月23日より前に作成されたMySQLの5.5 DBインスタンスは自動的にコンソールを使用してアップグレードすることはできません。

パターン①

1. MasterのRDS（MySQL5.5）からRead Replica（MySQL5.5）を作成。 2. Read ReplicaのMySQLを5.6へアップグレード。 3. MySQL5.6になったRead ReplicaをMasterへ昇格。

手順1
MasterからRead Replicaを作成します。

MasterのRDSインスタンスを選択し、Instance Action->Create Read Replica。
この時にPIOPSの設定をするかしないかでRead Replicaが作成される時間が変わってきます。
※約80GBのStorageのRead Replica（PIOPS無し）を作成するのに、約3時間ほど。。。
PIOPSなしに設定しても、一度MasterのPIOPSを設定した後に、PIOPSを外す処理が走っている感じ？
本番稼働中でもRead Replicaは作成可能ですが、やはりMasterに負荷が掛かってしまうので、注意。

手順2
Read ReplicaのMySQLを5.6へアップグレード
Read Replicaを選択し、Modify->DB Engine VersionからMySQL5.6を選択。
Apply Immediatelyにチェックを入れて、即反映。

アップグレード中も同期されているので、Read Replica作成時と同様に本番稼働中でも負荷に注意しつつ作業は可能。
アップグレード完了後は、SHOW SLAVE STATUSコマンドでSeconds_Behind_Masterの値を確認し、「 0 」であれば最新の状態。

手順3
Read ReplicaをMasterへ昇格。
Instance Action->Promote Read Replica

この時はMasterが読み取り専用で、すべてのトランザクションが中断されることに注意。
昇格作業からはメンテナンスモードなどにした方が安全です。
必要であれば、MultiAZ化やRead Replica作成を行いましょう。
ここまでがパターン①の手順です。

パターン②

1. MasterのRDS（MySQL5.5）からSnapshotを取得。 2. SnapshotからRDS（MySQL5.5）を復元。 3. 復元したRDSのバージョンを5.6へアップグレード

手順1
MasterからSnapshotを取得

MasterのRDSからSnapshotを取得。
その状態のSnapshotから復元を行うので、本番サービスをメンテナンスモードなどに切り替えデータの書き込みが無い状態にしておく。
でないとSnapshotの内容とMasterのRDSとで差分が出来てしまうので要注意。

手順2
SnapshotからRDSを復元
Snapshots->ManualSnapshots->Restore Snapshots

手順3
復元したRDSのMySQLバージョンを5.6へアップグレード
Read Replicaを選択し、Modify->DB Engine VersionからMySQL5.6を選択。

パターン①のアップグレードと同様の注意が必要。
ここまでがパターン②の手順です。

メリット・デメリット

パターン① メリット ・AWS推奨パターン。リードレプリカを作り同期させながら作業するので、差分が発生しない。

デメリット
・リードレプリカを作る時に時間が掛かる。

パターン②
メリット
・パターン①に較べて全体の作業時間が短い。検証した時は約1時間ほどで完了（約80Gの容量）

デメリット
・AWS非推奨パターン。Snapshotを取得するときにデータ書き込みがあると差分が発生してしまう。

まとめ

AWS推奨パターンの①がおすすめです。ただPIOPSを設定するかしないかで時間がかなり変わってきます。 パターン①を用いて、業務でアップグレードを行いましたが約80GBの容量で約3時間ほどの時間が掛かりました。（↑で紹介した手順にさらにMultiAZ化とリードレプリカ作成を含む） リードレプリカ作成時に自動的にSnapshotが作成されるのですが、これに大きく時間が掛かったように思えます。 実際にアップグレードする場合は、前日など前もってリードレプリカを用意しておき、当日の作業手順を省くとよいかと思います。

それにしても初めての本番環境アップグレードは緊張しました。。。