マルチAZ構成のRDS(MySQL)を強制フェイルバックさせてみた

はじめに

AWSチームのすずきです。

マルチAZ構成で作成されたRDS(MySQL)は、メンテナンスウィンドウによるインスタンスタイプやストレージ容量の変更後、 マスタDBの稼働するアベイラビリティーゾーン(AZ)がフェイルオーバーにより変化する事があります。

【AWS】RDSのインスタンスタイプ変更にかかる時間を調べてみた

EC2とRDS間の通信がクロスAZとなる事で、レイテンシの増加やAZ間のネットワーク転送費(0.01$/GB)が問題となる環境で、 手動フェイルオーバーを実施する機会がありましたので紹介させて頂きます。

構成図

• EC2、RDS間の通信がクロスAZとなった環境(右)、フェイルバックにより復旧させました。

操作

再起動

• 手動(強制)フェイルオーバは、RDSの再起動で実施します。

• 「フェイルオーバし再起動」をチェックし、再起動を行います。

• 通常、数分でフェイルオーバが完了、RDSのイベント情報に反映されます。

確認

• AWSコンソールの「アベイラビリティーゾーン」表示、CLIの「describe-db-instances」の「AvailabilityZone」の表示は、手動フェイルオーバ後の更新にラグが有る場合があります。

• 今回の手動フェイルオーバでは再起動操作の約3分後、「describe-db-instances」で表示されるAZの変更が確認できました。

• エンドポイントの名前解決で正引きで求めたIPアドレス情報を求め、意図したAZのサブネットに所属するIPアドレスである事でフェイルバックの完了を確認可能です。

フェイルオーバ前

$ host ####.#####.ap-northeast-1.rds.amazonaws.com
####.#####.ap-northeast-1.rds.amazonaws.com has address 172.21.21.##

フェイルオーバ後

$ host ####.#####.ap-northeast-1.rds.amazonaws.com
####.#####.ap-northeast-1.rds.amazonaws.com has address 172.21.1.##

まとめ

マスタDBのAZ変更が問題となる環境では、フェイルオーバを伴う設定変更は深夜無人時間帯のメンテナンスウィンドウではなく、 有人対応可能時間帯に計画メンテナンスで実施される事をおすすめします。

RDSのフェイルオーバは計画外の障害などでも発生しうるため、フェイルバックを必須とするDBの存在は潜在的なリスクとなります。 多くのDBアクセスを行うジョブのDB利用が参照のみの場合にはリードレプリカインスタンスの活用。 また、同一AZ内に設置したリードレプリカを明示したフェイルオーバが可能なAuroraの採用もご検討ください。

[新機能]RDS for Auroraでフェイルオーバー先の優先順序を指定できます