こんにちは、ちゃりおです。
この前、RDSのリードレプリカのHWメンテナンスがありました。
メンテナンスによって、メンテナンスウィンドウ内に数分停止してしまいます。
停止するのを避けたいという要望があったので、手間はかかりますが停止しない方法についてです。
Contents
環境
RDSマスター(シングルAZ) × 1
RDSリードレプリカ × 1
今回は、RDSリードレプリカがメンテナンス対象になりました。
対策
リードレプリカをもう一台作って、アプリケーションの接続先を変更する。
メンテナンスによるダウンタイムは避けたかったので
新規にリードレプリカを作成し切り替えて古い方は削除する方法で対応しました。
手順
マスターをマルチAZにする
公式ドキュメントによるとシングルAZの場合、スナップショットの作成のため１分間のI/O停止が発生します。
マルチAZにすることで、I/O停止を回避できます。
リードレプリカを作成すると、Amazon RDS はソース DB インスタンスの DB スナップショットを取得し、レプリケーションを開始します。その結果、DB スナップショットを作成する間、ソース DB インスタンスに短期間の I/O 停止が発生します。I/O 停止は通常、約 1 分間続きます。ソース DB インスタンスがマルチ AZ 配置の場合は、I/O 停止を回避できます。スナップショットがセカンダリ DB インスタンスから取得されるためです。
また、マルチAZにする際もダウンタイムは発生しません。
AWSユーザガイド DBインスタンスを変更してマルチAZにする
リードレプリカをもう一台作る
マルチAZになったことを確認したら、リードレプリカを作成します。
だいたい１０分以内で作成されます。
マスターをシングルAZに戻す
マルチAZのままだと、料金がかかってしまうのでシングルAZに戻します。
この際も、ダウンタイムは発生しません。
アプリケーションのリードレプリカの接続先を変更する
Route53でCNAMEでエンドポイントを登録していなかったので
アプリケーションのリードレプリカの接続先を変更する必要がありました。(envにエンドポイント直書き)
Route53で登録している場合は、該当ドメインのレコードを書き換えるだけでコードを変更する必要ありません。
古いリードレプリカを削除する
切り替えが終わって、動作確認ができたら古いリードレプリカを削除します。
所感
Route53でRDSのエンドポイント指定しておけば、楽でした
あとは、リードレプリカは用途ごとに作っておいたほうがいいと感じました。
アプリケーションからの参照系と分析用を兼用していました。
参照系のリードレプリカはできれば止めたくないですが、分析系は多少とまっていても大丈夫だったので
変更範囲は減らすことができました。
メンテナンスウィンドウ内のダウンタイムを受け入れる方針にすれば、手間はなかったのですが
今後DBをAuroraに移行するなど検討しているのでいい予行練習になった気がします。
