今回はお仕事の中でMulti-AZなRDS MySQLのクラス変更について調査＆問い合わせた結果わかったことです。
（ちなみに「わかった」ものの調査が遅きに失してお仕事には活かされず😅）
後述するRDS MySQL Multi-AZのクラス変更の処理の流れについては、調査＆問い合わせの結果を想像で補っている部分があります。RDS基盤の処理の詳細についてはAWS外部に開示不可のためです。
Background
Multi-AZでAmazon RDS MySQLのインスタンスを運用しているとします。
そしてそのインスタンスにクラス変更を行ったとします。
例えば、 db.t3.medium を db.m5.large に変更したり、 db.m5.2xlargeを db.r7g.xlargeに変更したり。
ご存知の通り、Multi-AZのRDSをクラス変更する場合、おおよそ次のようにことが進みます：
- クラス変更の開始（AWS管理コンソールほか起動方法は複数あり）
- スタンバイ側のクラス変更
- フェールオーバー（スタンバイがプライマリに、プライマリがスタンバイに切り替わる） ※ここでダウンタイム発生 数十秒～数分
- スタンバイ側（#3より前はプライマリだった側）のクラス変更
- クラス変更の完了
絵的にすると・・・
このようなプロセスのおかげで、クライアントからデータベースへの接続のダウンタイムは最小限に抑えられます。
Question
では、クラス変更の#2や#4の最中に当該インスタンスに対してSQLコマンド実行しても大丈夫なのでしょうか？
ここで「大丈夫なのか？」とは、「プライマリ／スタンバイの間のデータ整合性が損なわれたり、クラス変更の処理過程に支障を来したりしないのだろうか？」ということです。
#2（左） や #4（右） の状態：
Anwser
大丈夫。
なぜなら・・・
- Multi-AZなRDSインスタンスのクラス変更は前述の通り 常にスタンバイ側で 実行されます。
- そしてこのとき、プライマリ→スタンバイへの データ同期は意図的に停止 されています。
- 同期再開に備えて、プライマリ側に加えられたデータの変更は記録 されます（これはおそらくREDOログやWALのような仕組みと想像しています）。
- スタンバイのクラス変更が完了すると、フェールオーバーが始まります。
- まず 同期停止中のプライマリ側で行われた変更がスタンバイ側に送信 されます。
- スタンバイ側でクラッシュリカバリが起動して、スタンバイ側に変更が反映されます。
- そしてプライマリとスタンバイが交代して、フェールオーバーが終わります。
- ・・・以下略。新スタンバイ側で同じようにクラス変更とクラッシュリカバリが行われ、データ同期が再開します。
絵的にすると・・・
まずはクラス変更開始前：
クラス変更を開始すると同期が停止され、まずはスタンバイ側でクラス変更：
フェールオーバーで、スタンバイ側に変更が反映され、RDSインスタンスのDNS名を名前解決した結果得られるIPがプライマリからスタンバイに変更：
引き続き、スタンバイ側（先程までプライマリだった側）でクラス変更：
スタンバイ側（先程までプライマリだった側）でクラッシュリカバリ：
最後に、同期レプリケーション再開：
なるほど。意図的な同期停止、停止中の変更の記録、そしてそれを用いたクラッシュリカバリ。
これならSQLコマンドからクラス変更中のスタンバイを守り、しかもSQLコマンドによる変更をスタンバイに完全に反映できます。
このような次第で、 SQLによるデータベース内の変更操作はDMLによるものであれDDLによるものであれ、クラス変更操作と競合しない形で、プライマリ→スタンバイへと完全に反映 されます。
参考記事
Amazon RDS よくある質問 のマルチ AZ 配置の「マルチ AZ のフェイルオーバー中どのようなことが起こるのですか? またこれはどれくらいの間継続するのですか?」
フェイルオーバーの際には、Amazon RDS は単純に DB インスタンスの正規名レコード (CNAME) を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。（・・・中略・・・）フェイルオーバーは、プライマリで障害が検出されてからスタンバイでトランザクションが再開されるまでの間隔として定義され、通常 1 ～ 2 分以内に完了します。コミットされていない大きなトランザクションを回復させる必要があるかどうかによっても、フェイルオーバー時間は異なります。
AWS re:Post のマルチ AZ 配置は、Amazon RDS MySQL の変更中のダウンタイムを削減するのに役立ちますか?の「DB インスタンスクラスの更新」
インスタンスクラスの変更には新たに定義されたハードウェアセットが必要であり、この変更はオンラインのオペレーションではないため、ダウンタイムが必要になります。Amazon RDS MySQL DB インスタンスのマルチ AZ 配置により、どのような影響も大幅に緩和できます。これは、更新がプライマリとスタンバイに対して同時に行われないためです。スタンバイインスタンスが最初に変更され、フェイルオーバーが発生します。フェイルオーバー後、新しいスタンバイが変更されます。必要なダウンタイムには、フェイルオーバーの完了 (通常は 60～120 秒) と DB エンジンのクラッシュリカバリの完了の時間が含まれます。詳細については、「マルチ AZ 配置」を参照してください。
Amazon Web Services ブログのAmazon RDS Under the Hood: Multi-AZの「接続に関する問題と同期」
問題または意図的な管理アクションのために、プライマリインスタンスとスタンバイインスタンスが相互に接続されていない場合があります。（・・・中略・・・）接続が復元した後、通常の進行中のレプリケーション状態に戻る前に、ボリュームの再同期を行う必要があります。
再同期プロセスにより、データの両方のコピーが一貫した状態に復元されます。再同期に必要な時間を短縮するために、プライマリは2つのインスタンスが切断されている間に変更されたブロックを追跡します。再同期が発生すると、それらの変更のみをプライマリインスタンスからスタンバイインスタンスに送信するだけでよく、プロセスが高速化されています。