Amazon Aurora MySQL をアップグレードする際の方式について整理してみました。いずれも一時的なダウンタイムは発生します。(ダウンタイムをゼロにする方法や、データ更新後も切り戻しできるようにする方法についてはここでは触れません。)
参考) Webinar: 忘れちゃいけない！データベースのアップグレード ～Aurora MySQL version 1 と(略)
方式 1. インプレースアップグレード
手順概要
- アプリケーションからの書き込みを停止
- データベースエンジンをアップグレード (アップグレード完了)
- 切り戻し用のスナップショットが作成される
Pros/Cons
- スナップショットをとる時間、ダウンタイムが発生する
- アップグレード完了後の切り戻しはスナップショットからのデータベース作り直しとなる
- アップグレード開始後に発生したデータ更新は消失する
方式 2. バックアップ＆レストアによるアップグレード
手順概要
- アプリケーションからの書き込みを停止
- スナップショットを作成
- スナップショットをアップグレード
- スナップショットからデータベースを作成
- アプリケーションからの接続先エンドポイントを切り替える (アップグレード完了)
- 元のインスタンスを削除
Pros/Cons
- ダウンタイムが長い
- アップグレード完了後の切り戻しが容易: アプリケーションからの接続先エンドポイントを元に戻す
- スナップショット作成後に発生したデータ更新は消失する
方式 3. クローンを使ったアップグレード
Aurora DB クラスターをクローンしてインプレースアップグレード後、切り替えをおこなう方法です。
参考) Amazon Aurora DB クラスターのボリュームのクローン作成
手順概要
- アプリケーションからの書き込みを停止
- Aurora DB クラスターをクローン
- 新しい Aurora DB クラスターのデータベースエンジンをアップグレード
- アプリケーションからの接続先エンドポイントを切り替える (アップグレード完了)
- 元の Aurora DB クラスターを削除
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 環境で使えるかは不明
Amazon RDS for MySQL との違いと注意点
- Amazon RDS for MySQL の場合はデフォルトでバイナリーログが有効だが、Aurora MySQL の場合はカスタムのクラスターパラメーターグループを作成してバイナリーログを有効にする必要がある。この設定変更にはリブートが必要になる。
- 作成された Green 環境はデフォルトで書き込み有効となっており(Amazon RDS for MySQL の場合は書き込み無効)、書き込みをおこなうとレプリケーションで競合が発生する場合がある。
Discussion