Help us understand the problem. What is going on with this article?

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

More than 5 years have passed since last update.

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

【背景】


業務で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を作成します。
2014 05 18 11 32 のイメージ
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にチェックを入れて、即反映。
2014 05 21 23 30 のイメージ
アップグレード中も同期されているので、Read Replica作成時と同様に本番稼働中でも負荷に注意しつつ作業は可能。
アップグレード完了後は、SHOW SLAVE STATUSコマンドでSeconds_Behind_Masterの値を確認し、「 0 」であれば最新の状態。

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

パターン②

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

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

手順2
SnapshotからRDSを復元
Snapshots->ManualSnapshots->Restore Snapshots
2014 06 01 1 44 のイメージ

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

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

メリット・デメリット

パターン① メリット ・AWS推奨パターン。リードレプリカを作り同期させながら作業するので、差分が発生しない。 デメリット ・リードレプリカを作る時に時間が掛かる。 パターン② メリット ・パターン①に較べて全体の作業時間が短い。検証した時は約1時間ほどで完了(約80Gの容量) デメリット ・AWS非推奨パターン。Snapshotを取得するときにデータ書き込みがあると差分が発生してしまう。

まとめ

AWS推奨パターンの①がおすすめです。ただPIOPSを設定するかしないかで時間がかなり変わってきます。 パターン①を用いて、業務でアップグレードを行いましたが約80GBの容量で約3時間ほどの時間が掛かりました。(↑で紹介した手順にさらにMultiAZ化とリードレプリカ作成を含む) リードレプリカ作成時に自動的にSnapshotが作成されるのですが、これに大きく時間が掛かったように思えます。 実際にアップグレードする場合は、前日など前もってリードレプリカを用意しておき、当日の作業手順を省くとよいかと思います。 それにしても初めての本番環境アップグレードは緊張しました。。。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした