sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

RDSのDBのバージョンアップは計画的に [cloudpack OSAKA blog]

ども、ナスです。

RDSで動いているDBエンジンのバージョンアップをしたい場合に、気をつけないといけないことがあることが今日分かったのでpostすることにしました。

docs.aws.amazon.com

このページに、RDS共通でのポイントと、各エンジンごとのポイントが書かれています。マイナーバージョンアップだとこうですよとか、メジャーバージョンアップだとこうなりますよ、とか。どのバージョンからどのバージョンにあげられるとかはドキュメント読めばすぐわかるので置いといて、問題はサービス停止することなくアップグレードできるのか?という点です。

で、よくよく上のページを読んでいくと、

マルチ AZ インスタンスであっても DB エンジンバージョンのアップグレードにあたってはダウンタイムが発生するため、お客様が対応を計画できるようにアップグレードをスケジュールしています。

マルチAZでも問答無用でサービス停止しちゃうそうです。これはなかなか厳しい。障害時のことをよく考えているマルチAZですが、アップグレードの動きには全くメリットを活かせていません。

リードレプリカだったら大丈夫なんじゃないか!?と思って読み進めていくと、

DB インスタンスがマルチ AZ 配置にある場合、プライマリとスタンバイのレプリカの両方がアップグレードされます。プライマリとスタンバイの DB インスタンスは同時にアップグレードされ、アップグレードが完了するまで停止します。

と悲しい文言が。リードレプリカを使っている場合は、アップグレードの順序も大切です。

ご使用の DB インスタンスでリードレプリカを使用している場合は、ソースインスタンスのアップグレード前に、すべてのリードレプリカをアップグレードする必要があります。

障害発生時のことを考えてマルチAZ構成にしてるから、アップグレード作業やったら大丈夫やろ!と思い込んで作業すると大変な目にあうことになりますので、皆さん本当に気をつけましょう。