[小ネタ] RDSのMulti-AZ構成を切り替える手順

しばたです。

例えばですが、システム開発においてRDSを利用するにあたり開発期間中はSingle-AZ構成にしてランニングコストを節約、受入テストや本番稼働の際にMulti-AZにして可用性を確保するといった運用は良くあるかと思います。

本記事ではこういった場合のためにRDSのMulti-AZ構成を切り替える手順について解説します。

検証環境

本記事では私が慣れているRDS for Oracle(Oracle 19c SE2, db.m5.large)で説明します。
他のRDBMSでも基本同様の手順となります。

また、RDSを構成するネットワーク設定およびRDSインスタンス自体は構築済みの前提です。

1. Multi-AZ構成からSingle-AZ構成に変更する

まずはMulit-AZ構成の環境をSingle-AZ構成にする方法を紹介します。

最初にマネジメントコンソールからRDSサービスを選択し、構成を変更したいRDSインスタンス(ここではtest-db-19)を選択します。
RDSインスタンスを選択した状態で「変更」ボタンをクリックします。

RDSの設定変更画面に遷移しますので、「マルチAZ配置」欄の設定を「はい」→「いいえ」に変更します。

その他の項目は一切変更せずに画面下部の「次へ」ボタンをクリックします。

すると確認画面に遷移しますので、内容に間違いがないのを確認し変更のスケジュールを決めて「DBインスタンスの変更」ボタンをクリックします。
今回は「すぐに適用」を選び変更が直ちに実施される様にしています。

これで設定変更は完了です。
RDSインスタンスのステータスが「変更中」に切り替わるのでしばらく待ちます。

すべての内部処理が完了しステータスが「利用可能」に戻れば完了です。

変更の実績についてはイベントログにも記録されます。

待ち時間についてはRDBMSの種類やインスタンスタイプによって微妙に変わるでしょう。
今回の環境では約4分ほどかかりました。
待ち時間を厳密に要求される場合は検証環境を用意して事前に計測しておくと良いと思います。

補足1 : プライマリとなるAZについて

ここまでの手順ではプライマリとなるAZを指定する箇所がありませんでした。
Multi-AZからSingle-AZに変更する際はプライマリのAZはそのままで変更できません。

また、プライマリのAZを変更するのはMulit-AZ構成の時のみ可能です。

https://dev.classmethod.jp/articles/rds-singleaz-change-az/

このため、Multi-AZからSingle-AZに切り替えつつプライマリのAZも変更したい場合は、

1. 最初にMulti-AZの状態でプライマリAZを変更 (手動フェイルオーバー)
2. Multi-AZからSingle-AZに変更

のステップを踏む必要がありますので気をつけてください。

補足2 : プライマリAZの変更手順 (手動フェイルオーバー)

上記記事で解説されてますがこの記事でも簡単にプライマリAZの変更手順を紹介しておきます。

変更したいRDSインスタンスを選択した状態で「アクション」から「再起動」を選択します。

再起動の確認画面に遷移するので「フェイルオーバーし再起動しますか？」にチェックを付けて「再起動」します。

これでフェイルオーバー（＝プライマリAZの切り替え）を実施しつつRDSインスタンスの再起動が実施されますので、再起動が完了まで待てばOKです。

2. Single-AZ構成からMulti-AZ構成に変更する

次にSingle-AZ構成の環境をMulit-AZ構成にする方法を紹介します。
手順としては前節の手順の逆を行う形になります。

マネジメントコンソールからRDSサービスを選択し、構成を変更したいRDSインスタンス(ここではtest-db-19)を選択します。
RDSインスタンスを選択した状態で「変更」ボタンをクリックします。

RDSの設定変更画面に遷移しますので、「マルチAZ配置」欄の設定を「いいえ」→「はい」に変更します。

その他の項目は一切変更せずに画面下部の「次へ」ボタンをクリックします。

確認画面に遷移しますので、内容に間違いがないのを確認し変更のスケジュールを決めて「DBインスタンスの変更」ボタンをクリックします。
Mulit-AZに変更する場合はパフォーマンスに大きな影響が出るとの警告が出ているのが前節と少し異なっています。
今回も「すぐに適用」を選び変更が直ちに実施される様にしています。

これで設定変更は完了です。
RDSインスタンスのステータスが「変更中」に切り替わるのでしばらく待ちます。

すべての内部処理が完了しステータスが「利用可能」に戻れば完了です。

変更の実績はイベントログに記録されます。

待ち時間は今回の環境では約4分ほどかかりました。
こちらも厳密な待ち時間が要求される場合は検証環境を用意して事前に計測しておくと良いでしょう。

最後に

以上となります。
なんてことの無い手順ですが良くあるケースだと思いますのでブログとしてまとめておくことにしました。

今回はマネジメントコンソールからの手順を紹介しましたが同様の手順をAWS CLI等から行うことももちろん可能です。
要件に応じて適切な方法を選ぶと良いでしょう。