前置き
今回調査した内容は、RDSの作業の中でDBのダウンタイムが発生するものをまとめたものになります。
調査対象は、RDS for MySQLとしています。
ダウンタイムの発生する作業一覧
ダウンタイムが発生する作業として以下のものが挙げられます。
スケールアップのためのインスタンスの変更やメンテナンスウィンドウに通知されるアップグレード作業はダウンタイムとなる場合があります。
- DBエンジンバージョンのアップグレード
- インスタンスの昇格
- インスタンスの変更
- OSのアップグレード
マルチAZ配置
上記のような作業を実施する場合や障害に備える必要があります。
そこで、2つ以上のAZにDBインスタンスを配置して片方のインスタンスのダウンタイムに合わせてフェイルオーバーを行う方法があります。
これをマルチAZ配置と言います。
メインとなるAZに配置されたインスタンスをプライマリインスタンス、異なるAZに配置されたインスタンスをセカンダリインスタンスと呼びます。
実際のフェイルオーバーは次のような流れで行われます。
フェイルオーバーの流れ
一部例外を除いて、障害やインスタンスの変更などによるフェイルオーバー発生時は、ダウンタイムが最小となるように動作します。
以下の例は、インスタンスの変更を実施したときの変更作業完了までの流れです。
1.インスタンスの変更があった場合、セカンダリインスタンスから変更作業を開始します。
2.セカンダリインスタンスの変更完了後、フェイルオーバーが発生し、プライマリと入れ替わります。
3.入れ替わり後、元プライマリインスタンスの変更作業が開始されます。
4.変更作業が完了すると、インスタンスの変更作業が終了します。なお、フェイルバックは行われません。
マルチAZとすることで、変更作業のダウンタイムはフェイルオーバーが発生するごく短い時間だけとなります。
マルチAZ構成でもダウンタイムが発生してしまうDBエンジンアップグレード
公式のドキュメントによると、DBエンジンのアップグレード作業は、プライマリインスタンスとセカンダリインスタンスに同時に実施されるため、マルチAZ配置に関わらず、ダウンタイムが発生してしまうそうです。
一応、ダウンタイムを短縮してアップグレードをする方法が掲載されていました。以下リンクを参考にしてください。
参考
必要な Amazon RDS メンテナンスの実行時におけるダウンタイムを最小限に抑えるにはどうすればよいですか?
Amazon RDSでのMySQL
##後書き
今回は、RDSでダウンタイムが発生する作業を調査しました。
ダウンタイムはなるべく短縮した方が良いので、マルチAZとフェイルオーバー時の挙動を確認できたのは良かったです。
初心者の拙い文章ですので、ご指摘・訂正がありましたら遠慮なくお願い致します。