RDS Multi-AZ failover には2種類ある — 別 AZ 切替と同一 AZ 復旧の見分け方
まとめ
- RDS Multi-AZ の failover は「別 AZ への切替」と「同一 AZ での復旧」の2パターンがある
RDS-EVENT-0015(Multi-AZ failover to standby complete) → 別 AZ への切替RDS-EVENT-0050/0051(Multi-AZ instance activation) → 同一 AZ での復旧DB instance restartedの件数で判別するのは公式に保証されていない。イベント ID で判定するのが正攻法- リアルタイム判定なら MySQL の
@@hostnameを SQL で問い合わせるのが最速。describe_db_instancesの AZ メタデータは数分単位でラグする
何が困ったか
reboot_db_instance(ForceFailover=True) を実行して Multi-AZ instance failover completed イベントが出ていたので「フェールオーバー成功＝AZ が切り替わった」と思い込んでいたが、describe_db_instances を見ると Primary AZ が変わっていない。AWS コンソールでも同じ AZ のまま。実際にはフェールオーバーが同一 AZ 内で完結していたケースだった。
公式イベントで明確に区別できる
AWS RDS のイベントメッセージは公式で以下のように定義されている。
| Event ID | Message | 意味 |
|---|---|---|
| RDS-EVENT-0013 | Multi-AZ instance failover started. | 開始 |
| RDS-EVENT-0015 | Multi-AZ failover to standby complete - DNS propagation may take a few minutes. | 別 AZ の Standby を新 Primary に昇格 |
| RDS-EVENT-0049 | Multi-AZ instance failover completed. | 汎用完了（AZ 変化の有無を問わない） |
| RDS-EVENT-0050 | Multi-AZ instance activation started. | 同一 AZ で再昇格開始 |
| RDS-EVENT-0051 | Multi-AZ instance activation completed. | 同一 AZ 再昇格完了 |
注目すべきは RDS-EVENT-0050 の説明:
A Multi-AZ activation has started after a successful DB instance recovery. This event occurs if Amazon RDS promotes the primary DB instance to the same AZ as the previous primary DB instance.
つまり「同じ AZ で Primary を再昇格させた」ことが明示的にこのイベントで通知される。RDS-EVENT-0049 の generic な「completed」だけ見ていると見逃す。
なぜ同一 AZ 復旧が起きるのか
ForceFailover=True をリクエストしても、Standby が利用可能でない・整合性がとれない等の事情があると AWS 側で「同一 AZ で Primary を再起動するだけ」に倒すことがある。それでも Multi-AZ instance failover completed のイベントは出るので、汎用 completed メッセージだけ見ていると気付けない。
「DB instance restarted」の件数は使えるか
経験的な観察として:
| ケース | DB instance restarted の件数 |
|---|---|
| 別 AZ への切替 | 2 回 |
| 同一 AZ で復旧 | 1 回 |
メカニズム的には納得できる（別 AZ 切替は2インスタンスが役割転換、同一 AZ 復旧は Primary だけ再起動）。ただし AWS 公式に「restart 件数で判別する」記述はない。判定ロジックには使わず補助情報として扱うのが安全。
DNS 伝播の落とし穴
別 AZ 切替が起きても describe_db_instances の AvailabilityZone はしばらく旧値を返す。RDS-EVENT-0015 のメッセージに DNS propagation may take a few minutes と書かれているとおり API メタデータにはラグがある。API 比較だけだと「変わっていない」と誤検出するので、イベントログで RDS-EVENT-0015 を検出していればラグに関わらず AZ 変化ありと言い切れる。
実測: API ラグと SQL ホスト名の差
10 秒間隔で describe_db_instances と MySQL @@hostname を併走モニタリングしたときのログ抜粋:
| 時刻 | Status | API の Primary AZ | MySQL @@hostname |
|---|---|---|---|
| 12:04:18 | available | ap-northeast-1c | ip-10-0-2-100 |
| 12:05:01 | rebooting | ap-northeast-1c | ip-10-0-2-100 |
| 12:05:21 | rebooting | ap-northeast-1c | ip-10-0-1-200 ← SQL 切替 |
| 12:06:12 | available | ap-northeast-1c | ip-10-0-1-200 |
| 12:13:41 | available | ap-northeast-1a ← API 切替 | ip-10-0-1-200 |
reboot 中の 20 秒以内に @@hostname が新ホストに切り替わっているのに対し、describe_db_instances の Primary AZ が新 AZ を返すまでは 約 8 分20 秒かかっている。失敗オーバー完了 (12:06:12) からカウントしても 7 分以上のラグ。
つまり API メタデータの「ラグ」は数分〜10 分弱の単位で、リアルタイムには使えない。即時に新 Primary を判定したいなら以下が早い:
- RDS イベント (
RDS-EVENT-0015/0050) — failover 直後にほぼ即時で発火 - DB に SQL を投げて
@@hostnameを取得 — 接続できれば現在値そのもの - エンドポイントの DNS 解決 (
nslookup) — Multi-AZ エンドポイントの CNAME は TTL 5 秒で更新される
Multi-AZ instance failover completed だけ見るのではなく、RDS-EVENT-0015 / RDS-EVENT-0050 か SQL 経由のホスト名で確認する運用にする。