今年の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インスタンスは自動的にコンソールを使用してアップグレードすることはできません。
パターン①
- MasterのRDS（MySQL5.5）からRead Replica（MySQL5.5）を作成。
- Read ReplicaのMySQLを5.6へアップグレード。
- 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作成を行いましょう。
ここまでがパターン①の手順です。
パターン②
- MasterのRDS（MySQL5.5）からSnapshotを取得。
- SnapshotからRDS（MySQL5.5）を復元。
- 復元した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が作成されるのですが、これに大きく時間が掛かったように思えます。 実際にアップグレードする場合は、前日など前もってリードレプリカを用意しておき、当日の作業手順を省くとよいかと思います。
それにしても初めての本番環境アップグレードは緊張しました。。。
