こんにちは。テクニカルサポート課の森本です。
RDSのバージョンアップグレードと他のメンテナンス(DBインスタンスクラスの変更など)を実施した際の挙動についてお問い合わせいただいた際に 改めてご注意いただきたい点がありましたのでまとめておきます。
主にこちらのドキュメントの記載内容の実例となります。
RDS for PostgreSQL のメジャーバージョンアップグレードの問題をトラブルシューティングする | AWS re:Post
何が発生したか
DB インスタンスの変更処理とバージョンアップグレード処理を同一のリクエストで行われており、先にDBインスタンスクラスの変更処理が実施され、その後バージョンアップグレード処理が行われました。
そのアップグレード前のバックアップ(スナップショット取得)に1時間以上の時間を要しておりました。
結果的にお客様が想定されていたメンテナンス時間中にアップグレード処理が完了しないという事態が発生していました。
環境
RDS PostgreSQL(マルチAZ構成)での問い合わせですが、マルチAZ構成の場合にスタンバイからスナップショットを取得する RDS MySQL や RDS Oracle でも同様の動作となる認識です。
*RDS SQL Server はマルチ AZ 構成時のスナップショット取得元やマイナーバージョンアップグレード時の挙動が他のデータベースエンジンとは異なるため、本ブログの考慮の対象外とします。
DBインスタンスクラス変更時の動作
マルチAZの場合、DBインスタンスクラスの変更時の動作は以下のようなステップとなります。
- スタンバイ側(新プライマリ側)で DB インスタンスクラスが変更される
- フェイルオーバーが行われる
- スタンバイ側(旧プライマリ側)で DB インスタンスクラスが変更される
マルチ AZ 配置とダウンタイムが Amazon RDS に与える影響 | AWS re:Post
Amazon RDS MySQL DB インスタンスのマルチ AZ 配置により、どのような影響も大幅に緩和できます。これは、更新がプライマリとスタンバイに対して同時に行われないためです。スタンバイインスタンスが最初に変更され、フェイルオーバーが発生します。フェイルオーバー後、新しいスタンバイが変更されます。
DB インスタンスクラスの変更完了後、変更前のプライマリ/スタンバイに戻る処理(=フェールバック処理)は自動では行われません。
エンジンバージョンアップグレード時の動作
RDSの自動バックアップが有効な場合、バージョンアップグレード処理は以下のようなステップとなります。 こちらはシングル AZ/マルチ AZ 構成に関わらず同じです。
- アップグレード前のスナップショットを取得
- DBインスタンスをアップグレード
- アップグレード後のスナップショットを取得
スナップショット取得時の動作
RDS PosgreSQLを使用していてマルチ AZ 構成の場合、バックアップはスタンバイから取得されます。 DB インスタンスから取得する最初のスナップショットはフルバックアップ、後続のバックアップは直近のスナップショットからの増分バックアップです。
DB スナップショットの作成 - Amazon Relational Database Service
Amazon RDS は DB インスタンスのストレージボリュームのスナップショットを作成し、個々のデータベースだけではなく、その DB インスタンス全体をバックアップします。Single-AZ DB インスタンスでこの DB スナップショットを作成すると、I/O が短時間中断します。この時間は、DB インスタンスのサイズやクラスによって異なり、数秒から数分になります。MariaDB、MySQL、Oracle、PostgreSQL の場合、バックアップはスタンバイから取得されるため、マルチ AZ 配置のバックアップ中プライマリで I/O アクティビティは中断しません。
バックアップの使用 - Amazon Relational Database Service
DB インスタンスの最初のスナップショットには、データベース全体のデータが含まれます。同じ DB インスタンスの後続のスナップショットは増分です。つまり、直近のスナップショットの保存後に変更されたデータのみが含まれます。
原因
DB インスタンスクラス変更によりフェイルオーバーが行われたことにより、バックアップ取得元の DB インスタンスも変更(旧プライマリ/新スタンバイ)となりました。
過去のDB インスタンスの自動バックアップ保持期間内を遡ってもフェイルオーバーは発生していなかったため、このスナップショット取得元の DBインスタンス(旧プライマリ/新スタンバイ)で取得された自動/手動スナップショットも存在しておりませんでした。
そのため、マイナーバージョンアップグレード直前に取得するバックアップが意図せずフルバックアップとなっており、スナップショット取得に時間を要しておりました。
結論
DBインスタンスクラス変更時の動作、マイナーバージョンアップグレード時の動作、スナップショット取得の動作それぞれについては RDS の仕様上は期待される動作であり、特に不具合のある動作ではありません。 しかし、実施する順番やタイミングによっては本事象のようなことは発生しうる可能性があります。
本事象に関しては DB インスタンスクラスの変更だけではなく、フェイルオーバーを伴うメンテナンスとデータベースエンジンバージョンのアップグレードを同時に行う場合にも発生し得ます。
エンジンバージョンアップグレードに長時間を要する事象を防ぐため、エンジンバージョンのアップグレードと同じタイミングでの変更が行われないような運用をしていただきたいですね！
この記事がどなたかのお役に立てば幸いです。
参考資料
RDS for PostgreSQL のメジャーバージョンアップグレードの問題をトラブルシューティングする | AWS re:Post
マルチ AZ 配置とダウンタイムが Amazon RDS に与える影響 | AWS re:Post
DB スナップショットの作成 - Amazon Relational Database Service
バックアップの使用 - Amazon Relational Database Service
