読者です 読者をやめる 読者になる 読者になる

ニクニクドットミー

カッコいいおっさんを目指すエンジニアの厳かなブログ

スポンサーリンク

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

AWS RDS

aws log 今年の3月にインフラチームへ移動してから早2ヶ月。 日々刺激的?な毎日を過ごしています笑   さて、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を作成します。 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が作成されるのですが、これに大きく時間が掛かったように思えます。 実際にアップグレードする場合は、前日など前もってリードレプリカを用意しておき、当日の作業手順を省くとよいかと思います。

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