2013年10月 RDSのマイナーバージョンアップのお知らせとご留意事項について

2013年10月末から11月頭にかけてRDS MySQLのマイナーバージョンアップがAWSにより実施されます。
実施内容、時期などの詳細はこちらです。
この場をお借りして、マイナーバージョンアップされる対象やどうすればいいの？などをお知らせしたいと思います。
今回の対象はRDSでMySQLをお使いの場合のみです。Microsoft SQL Server（MS-SQL）やOracle Databaseは対象外です。 11月2日午前に、AWSから自動アップデートの実施中に内部的な問題が生じ作業を中断していたことが告知されました。新たなスケジュールが告知されるとのことです。手動でマイナーバージョンアップすることも可能です。

確認方法

まず、「自分のRDS MySQLは対象なの？」を確認しましょう。
AWS Management Consoleにログインして、メニューから「RDS」を選択します。

画像をクリックすると別ウィンドウで大きく表示されます

リージョンを確認します。
複数のリージョンにRDS MySQLを設置している場合は、リージョン毎に確認する必要があります。

画像をクリックすると別ウィンドウで大きく表示されます

画面左側のメニューで「Instances」をクリックしてRDSインスタンスの一覧を表示します。
Engineが「MySQL」となっているものが今回の対象です。
MySQLの各RDSインスタンスの「▶」をクリックして詳細を表示します。

画像をクリックすると別ウィンドウで大きく表示されます

各RDS MySQLインスタンスの詳細を表示したところです。
下記のように①〜④を確認します。

画像をクリックすると別ウィンドウで大きく表示されます

① … RDSのDNS名　アプリからこの名前でDBに接続します
② … MySQLのバージョン
③ … マイナーバージョンアップを自動で行なうか。行なうならいつ行なうか
④ … Multi-AZ（冗長化）しているか

対象であるか確認の方法

上記①〜④で確認した内容で対象であるか、対象であればどう対処すれば良いのか説明します。
順にお読みになると、お使いのRDS MySQLが対象であるかが絞り込めます。

① RDSのDNS名

DBの名前です。このDBが影響を受ける（かもしれない）DBです。

② MySQLのバージョン

お使いのMySQLが下記のメジャーバージョンのどれかを確認してください。
次に、マイナーバージョンを確認し、表記のバージョンより古い（数字が小さい）のであれば対象になる（かもしれない）DBとなります。

メジャーバージョン	マイナーバージョン
5.1系	5.1.71より小さい
5.5系	5.5.33より小さい
5.6系	5.6.13より小さい

例）5.5.27をお使いの場合 … 5.5.33より古いので対象になります。
例）5.6.13をお使いの場合 … 最新ですので、今回の対象外になります。

③ マイナーバージョンアップを自動で行なうか

この値が「Yes」であれば、今回の対象になります。
「No」である場合は、自動でマイナーバージョンアップは行われないので、今回は対象外になります。
ただし、今後AWSにサポートを求めた時に、「最新のバージョンにしてみて」と言われるかもしれません。下記のメンテ期間の間で、項目「Maintenance Window」で指定された曜日・時刻に実施されます。
「Maintenance Window」で設定されている時刻はUTCです（日本時間ではありません）のでご注意ください。

リージョン	メンテ期間（UTC時間）	メンテ期間（日本時間）
東京	10月30日21:00〜11月6日20:59	10月31日6:00〜11月7日5:59
バージニア	10月30日21:00〜11月6日20:59	10月31日6:00〜11月7日5:59
アイルランド	10月30日21:00〜11月6日20:59	10月31日6:00〜11月7日5:59
カリフォルニア	10月29日21:00〜11月5日20:59	10月30日6:00〜11月6日5:59
オレゴン	10月29日21:00〜11月5日20:59	10月30日6:00〜11月6日5:59
シンガポール	10月28日21:00〜11月4日20:59	10月29日6:00〜11月5日5:59
シドニー	10月28日21:00〜11月4日20:59	10月29日6:00〜11月5日5:59
サンパウロ	10月28日21:00〜11月4日20:59	10月29日6:00〜11月5日5:59

メンテ期間内において、Maintenance Windowで指定された曜日の最初に該当した日のMaintenance Windowで指定された時刻に実施されます。
例えば、上記の画像ですと、東京リージョンでMaintenance Windowが「sat:14:56-sat:15:26」となっていますので、日本時間の11月2日23:56頃からバージョンアップ作業が始まります。　

④ Multi-AZ（冗長化）しているか

これについては、後述する対処方法で説明します。　

対処方法

対象であった場合、バージョンアップして良いか確認を行なってください。
もしかしたら、バージョンを上げたらDBに接続しているアプリに不具合が出るかもしれません。
開発環境・テスト環境・ステージングなどでバージョンを上げても大丈夫かを確認してください。　

上げても大丈夫と分かったら…

下記のメンテ期間のうち、上記③で確認した「Maintenance Window」で指定した曜日・時刻にバージョンアップが実施されます。　

④ Multi-AZが「Yes」となっている場合

まず待機系（スタンバイ）がマイナーバージョンアップされます。（この間はDBに接続できます）
待機系のマイナーバージョンアップが終わるとフェイルオーバーします。待機系がマスタになります。
このマスタ／スタンバイの切り替わりで数分から十数分ほど（あるいはもっと）DBに接続できなくなります。
（どのくらいの期間が接続できなくなるかは実際にやってみないと分かりません）
切り替わった後、バージョンアップされた待機系が新しいインスタンスで起動されレプリケーションが行われます。　

④ Multi-AZが「No」となっている場合

まずRDS MySQLがシャットダウンされます。（この時点でDBに接続できなくなります）
バージョンアップが施されてRDS MySQLが再起動されます。
再起動が終えて通常稼働に戻ると再びDBに接続できるようになります。
つまり、バージョンアップが施されるのを待つ間、Multi-AZが有効の状態よりもDBを使えない時間が長くなります。メンテ期間に入る前に一時的にMulti-AZを有効にして、DBが使えなくなる時間を短くすることもできます。（バージョンアップが終わったらMulti-AZを無効にする）
この場合は、メンテ期間に入るまでにレプリケーションが完全に行われるようにする余裕が必要になります。
（DBには失っては困ったり、リストア時に定期バックアップから漏れたデータを戻しきれない場合がありますので、これを期にMulti-AZを有効にすることをオススメします）　

上げてはマズイ場合…

「③ Minor Version Upgrade」をメンテ期間内において「No」にして、バージョンアップされないようにするという手段があります。
この「No」にする操作を行なう時は、RDS MySQLの再起動は起こりません。
ただし、アプリの動作に不具合が起きないと確認できましたら、これで時間稼ぎをしておいて、いつかはバージョンアップすることをオススメします。　

さらにご注意

リードレプリカをご利用している場合は、更に確認が必要になります。
リードレプリカの「Auto Minor Version Upgrade」が「Yes」なのか「No」なのかをご確認ください。
「Yes」であれば上記の『Multi-AZが「No」となっている場合』と同様の動きでマイナーバージョンアップされます。　