Amazon RDS for MySQL をアップグレードする際の方式について整理してみました。いずれも一時的なダウンタイムは発生します。(ダウンタイムをゼロにする方法や、データ更新後も切り戻しできるようにする方法についてはここでは触れません。)
参考) Amazon RDS Online Seminar 「忘れちゃいけない！Amazon RDS/Amazon Aurora のアップグレードとその方法」
方式 1. インプレースアップグレード
動作しているインスタンスを直接アップグレードする方式です。Multi-AZ 構成であればアップグレード自体のダウンタイムは短時間(通常1~2分)で済みますが、アップグレード後に問題があった場合に切り戻しできるよう、バックアップをとる時間が必要です。
手順概要
- アプリケーションからの書き込みを停止
- データベースエンジンをアップグレード (アップグレード完了)
- 切り戻し用のスナップショットが作成される
Pros/Cons
- スナップショットをとる時間、ダウンタイムが発生する
- アップグレード完了後の切り戻しはスナップショットからのデータベース作り直しとなる
- アップグレード開始後に発生したデータ更新は消失する
方式 2. バックアップ＆レストアによるアップグレード
手順概要
- アプリケーションからの書き込みを停止
- スナップショットを作成
- スナップショットをアップグレード
- スナップショットからデータベースを作成
- アプリケーションからの接続先エンドポイントを切り替える (アップグレード完了)
- 元のインスタンスを削除
Pros/Cons
- ダウンタイムが長い
- アップグレード完了後の切り戻しが容易: アプリケーションからの接続先エンドポイントを元に戻す
- スナップショット作成後に発生したデータ更新は消失する
方式 3. レプリケーションを使ったアップグレード
レプリケーション先の Read Replica インスタンスをインプレースアップグレード後、昇格して切り替えをおこなう方法です。
参考) MySQL データベースのアップグレード時にリードレプリカを使用したダウンタイムの短縮
手順概要
- Read Replica インスタンスを作成
- レプリケーションが開始する
- Read Replica のデータベースエンジンをアップグレード
- アプリケーションからの書き込みを停止
- Replica Lag が 0 になっていることを確認して、Read Replica を昇格
- レプリケーションが停止する
- アプリケーションからの接続先エンドポイントを切り替える (アップグレード完了)
- 元のインスタンスを削除
Pros/Cons
- ダウンタイムが短い
- アップグレード完了後の切り戻しが容易: アプリケーションからの接続先エンドポイントを元に戻す
- 昇格開始後に発生したデータ更新は消失する
方式 4. Blue/Green Deployment 機能によるレプリケーションを使ったアップグレード
Blue/Green Deployment 機能で作成した待機系をインプレースアップグレード後、切り替えをおこなう方法です。
参考) データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する
手順概要
- Blue/Green Deployment を作成する
- Green 環境が作成される
- Blue -> Green 環境への論理レプリケーションが開始する
- Green 環境のデータベースエンジンをアップグレード
- Replica Lag が 0 になっていることを確認して、Switch over (アップグレード完了)
- レプリケーションが停止する
- エンドポイントの接続先が Green 環境に切り替わる
- Blue 環境を削除
Pros/Cons
- ダウンタイムが最小(通常1分未満)
- アプリケーションから接続先エンドポイントを変更する必要がない
- 切り替わるまでの時間は DNS の TTL に依存
- アップグレード完了後の切り戻しが容易: アプリケーションからの接続先エンドポイントを変更する
- Switch over 開始後に発生したデータ更新は消失する
- CloudFormation など IaC 環境で使えるかは不明
Discussion