Amazon RDS DB instance の system upgrades

## AWS から 届いた RDS Maintenance メール
>Subject:
>Amazon RDS Maintenance [AWS Account: xxxxxxxxxxxx]
>
>Body:
We are contacting you to inform you that one or more of your Amazon RDS DB instances is scheduled to receive system upgrades during your maintenance window between 2018-05-26 00:00 UTC (Saturday) and 2018-06-02 00:00 UTC (Saturday).
>Region DB Instance Identifier
>
> ================================================================
>ap-northeast-1 RDSインスタンス名
>
>While the system upgrades are in progress, Single-AZ deployments will be unavailable for a few minutes during your maintenance window. Multi-AZ deployments will be unavailable for the amount of time it takes a failover to complete, usually about 60 seconds, also in your maintenance window.
>
Please ensure the maintenance windows for your affected instances are set appropriately to minimize the impact of these system upgrades.
>
If you have any questions or concerns, contact the AWS Support Team. The team is available on the community forums and by contacting AWS Premium Support.
>
http://aws.amazon.com/support
>
Sincerely,
Amazon Web Services
>

## Amazonサポートへの問い合わせ
このRDSインスタンスが稼働しているAWSアカウントのサポートプランはベーシック。なので、突っ込んだ話は聞けないと思い、別のAWSアカウントの開発者プランから一般的な質問というていでAWSサポートへ問い合わせた。
### ●「 system upgrades 」の system とは何を指しているのでしょうか？
DB インスタンスの状況や、アップグレードの内容によって “system“ の指すものが異なります。
内部的な情報の場合、詳細をお伝えすることが出来ないこともございますが、DB インスタンスの ID を頂けましたら更に調査させていただきます。

### ●利用者側のタイミングで「 system upgrades 」を行なうことができるのでしょうか？
システムのアップグレードを任意のタイミングで実行できるかどうかに関しましては、ご利用いただいている DB インスタンスの状況や、システムのアップグレード内容によって異なります。

もし宜しければ、追加で調査させていただきますので、本メールの対象となっている DB インスタンスの ID を ご教示頂けますでしょうか。

### ●今回の場合は利用者側で問題が発生していてその事象に関する技術的問い合わせや調査依頼というわけでではなく、AWSから送信されたメールに記載のあるメンテナンス通知の内容をお答えしていただきたいのですが、そのような場合はその対象のDBインスタンスがあるAWSアカウントの "ベーシック" サポート でもご回答していただけるのでしょうか？
対象のリソースが別の AWS アカウント上のものであるとのこと、承知致しました。
メンテナンスの内容に関しましては、対象のリソースによって内容が大きく異なるため、一般的に回答することが出来ない旨、何卒ご理解いただけますと幸いでございます。
また、大変心苦しいのですが、セキュリティの都合上、異なるアカウントのメンテナンス内容については該当のアカウントで”開発者”以上のサポートプラン（※）に加入いただいてお問い合わせ頂けますでしょうか。
※ メンテナンスの内容についてのご質問は、技術サポート窓口より回答差し上げております。

### ●Aurora Master インスタンスでは「system upgrades」通知が無く、Aurora Replica インスタンスだけ 「system upgrades」通知が来た場合、Aurora Replica で「system upgrades」が実行された後も Aurora Replica の DBインスタンスエンジンのバージョンや、Auroraのバージョンは実行前と同じでしょうか？<br />もし、Aurora Replica で「system upgrades」が実行された後に DBインスタンスエンジンやAuroraの バージョンが上がる場合は、Auroraクラスター全体のインスタンスも同様にバージョンが上がることになると思います。<br />個人的見解では、「system upgrades」とは、物理的なインフラ環境・ホストサーバのシステムアップ グレード（仮想サーバのマイグレーション）なので、バージョンは上がらないのではないかと思っていますが。<br />過去の事例紹介でも良いので、教えて頂けますか？
過去の事象を確認させていただいた限り、system upgrades の内容はデータベースエンジンや OS のアップグ レードではなく、基本的にはお客様のデータベースの動作に変化を起こすものではございません。
したがいまして、お客様が懸念されている DB インスタンスの バージョンに変化はございません。
※ メールの本文にバージョンのアップグレードに関する記載が無い場合

## 対応
### EC2のメンテナンス通知が来た場合は、利用者側でEC2を再起動（停止⇒起動）すれば別の物理ホストで起動するので対応可能だけど、RDSの場合もRDSインスタンスを再起動すれば別の物理ホストで起動するのかどうかわからないし、それによってメンテナンス対応ができるのかどうかは不明なので、メンテナンス可能な時間を社内調整して、その時間帯をメンテナンスウィンドウに設定することに。
メールのアナウンスでは system upgrades の日程が 2018-05-26 00:00 UTC (Saturday) and 2018-06-02 00:00 UTC (Saturday) の間ということなので、wed:01:00-wed:01:30 (UTC) に設定。これは日本時間で 5/30(水)の10:00~10:30。

## メンテナンス実施
### マルチAZが "いいえ" のシングルインスタンスの場合
![image.png](https://qiita-image-store.s3.amazonaws.com/0/148868/fe6b8558-03fb-e218-3e91-c3a07db5c1be.png)
10:09にDBインスタンスが再起動された。

ちなみに、このDBインスタンスは Aurora master で、MySQLレプリケーションのマスターとしての役割も持っているのでbinlogを出す設定していて、MySQL on EC2 のスレーブへレプリケーションしている。
今回のDBインスタンス(Aurora master)の再起動によって、レプリケーションがエラーになってしまった。。

・Aurora master （メンテナンス対象のDBインスタンス）のレプリマスタ
>mysql> show slave hosts;
Empty set (0.00 sec)

・MySQL on EC2 のレプリスレーブ
>mysql> show slave status¥G
>〜
>             Slave_IO_Running: No
>〜
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

### マルチAZが "はい" のインスタンスの場合
・Auroraクラスター構成 - system upgrades 前
　・クラスターメンバーA・・・マスター（system upgrades対象のインスタンス）
　・クラスターメンバーB・・・レプリカ

・クラスターメンバーAのイベントログ
　![image.png](https://qiita-image-store.s3.amazonaws.com/0/148868/575c7227-92b1-7e0d-92de-05e18b0dd8c0.png)

・クラスターメンバーBのイベントログ
　![image.png](https://qiita-image-store.s3.amazonaws.com/0/148868/aeea953e-339b-4b57-da7a-d6e0ce1e690a.png)

・クラスターのイベントログ
　　![image.png](https://qiita-image-store.s3.amazonaws.com/0/148868/af0c0f8e-5ab8-e67e-2d80-38fc5294dd11.png)

・時系列
　・10:00:51〜10:00:56　クラスターメンバーB（レプリカ）が再起動
　・10:00:51〜10:01:20　フェイルオーバーで、クラスターメンバーAがレプリカに、クラスターメンバーBがマスターになる
　・10:02:53〜10:03:39　クラスターメンバーA（レプリカ）が再起動・・・system upgrades 完了

・Auroraクラスター構成 - system upgrades 後
　・クラスターメンバーA・・・レプリカ（system upgrades対象のインスタンス）
　・クラスターメンバーB・・・マスター