RDS for MySQLで、プライマリーのAZ障害を検知したら別AZへ自動切替したい。短時間の接続中断は許容するが、接続先の名前を手動変更する運用は避けたい。
アプリはRDSのDBエンドポイントを使い、切断後の再接続と適切なDNS再解決を実装する。読み取り負荷の分散は今回の主目的ではない。
最も適切な構成はどれか。
単一スタンバイのMulti-AZ DB instanceで自動切替を用意し、アプリは同じDBエンドポイントへ再接続する。
詳細解説
RDSが切替時にエンドポイントのDNSレコードを変更する。既存接続は再確立する必要がある。
昇格する運用は可能だが、この構成だけでは今回の自動切替の要件を満たさない。
データ復元はできるが、同期スタンバイへの自動切替と手動変更不要という要件とは異なる。
基盤は切り替わっても、IP固定ではDBエンドポイントのDNS更新へ追従できない。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料で単一スタンバイMulti-AZの用途、フェイルオーバーとDNS更新、既存接続の再確立を確認する。
参考にした公式資料
確認できる内容
エンドポイント名が同じでも接続中断があり得ることと、スタンバイを読み取り先にできない理由を説明できる。
理解のポイント
- RDS Multi-AZ DB instance
- スタンバイ
- RDSエンドポイント
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
単一スタンバイ構成の役割
この問題のDB instance deploymentは、別AZの同期スタンバイで高可用性を支える構成である。スタンバイは読み取り用の接続先ではない。読み取り可能なレプリカを持つMulti-AZ DB clusterや非同期Read Replicaとは構成と用途を区別する。
名前の維持と接続の維持を区別する
RDSは切替でDBエンドポイントのDNSを更新するが、既存接続は再確立する必要がある。通常60～120秒という切替時間は固定の保証ではなく、DB処理や回復状態によって長くなる。DNSキャッシュ、再試行、トランザクションの再実行を検証し、二重実行を避けてアプリの復旧を確認する。