Auroraのスナップショット復元で目的のバージョンを指定できない場合の対処法
Auroraのバージョンアップを行う際、万が一問題が発生した場合に備えて、事前にスナップショットを取得しておくことがあります。
しかし、いざ問題が発生してスナップショットから復元しようとすると、
「アップグレード前のバージョンが選択できない」
というケースがあります。
この記事では、Auroraのスナップショット復元で目的のエンジンバージョンを指定できない理由と、実際に検討すべきロールバック方法について整理します。
なぜ目的のバージョンを指定できないのか？
主な理由として、以下が考えられます。
1. サポート終了（End of Standard Support）したバージョン
Auroraでは、エンジンのメジャーバージョンごとに標準サポート期間があります。
標準サポート終了後のエンジンバージョンについては、通常のスナップショット復元でそのバージョンをそのまま復元できない場合があります。
AWS公式ドキュメントでも、Aurora標準サポート終了日を過ぎたDBエンジンバージョンには、スナップショットをそのまま復元できないと明記されています。
そのため、
アップグレード前
Aurora PostgreSQL 16.x
↓
スナップショット取得
↓
Aurora PostgreSQL 17.xへアップグレード
↓
問題発生
↓
スナップショットから16.xへ戻したい
↓
16.xが復元先として選択できない
という状況が発生する可能性があります。
つまり、
「スナップショットが存在する」＝「いつでも取得時点のバージョンへ戻せる」
ではありません。
2. マイナーバージョンアップ後に以前のバージョンへ戻したい
例えば、
16.6
↓
16.9
とマイナーバージョンをアップグレードしたとします。
その後、
16.9
↓
16.6
へ戻したいと考えても、16.6が復元先として利用できない場合があります。
特に、AWS側で対象バージョンが復元先として提供されなくなっている場合は、
「16.6時点のスナップショットがあるから16.6へ戻せる」
とは限りません。
そのため、アップグレード前のスナップショットだけをロールバック手段として考えるのは危険です。
対処法・代替手段
では、目的のバージョンへ戻せない場合はどうすればよいのでしょうか。
状況に応じて、以下の方法を検討します。
1. 🔵 Blue/Green Deploymentsを利用する【推奨】
本番環境のアップグレードでは、可能であればAurora Blue/Green Deploymentsを利用する方法があります。
Blue/Greenでは、
Blue
現在の本番環境
Aurora 16.x
│
│ コピー・同期
▼
Green
アップグレード検証環境
Aurora 17.x
という構成を作ります。
Green側でエンジンバージョンアップやパラメータ変更などを事前に検証できます。
問題がなければGreenへ切り替えます。
AWS公式ドキュメントでも、Blue/Green Deploymentsでは本番環境を維持したまま、別環境でメジャー・マイナーバージョンのアップグレードを実施できるとされています。
イメージ
【アップグレード前】
Blue（本番）
16.x
│
└── Green
16.x
↓ Green側をアップグレード
Blue（本番）
16.x
Green
17.x
│
├─ 動作確認
├─ 性能確認
└─ アプリケーション確認
↓ 問題なし
Greenを本番へSwitch Over
↓
17.xが本番
Blue/Greenの大きなメリットは、切り替え前まで旧環境を維持できることです。
そのため、「スナップショットから旧バージョンへ戻せるか」という問題そのものを減らせます。
なお、Blue/Greenの切り替えは単純な「Greenの手動プロモート」とは異なります。AWSはBlue/Green DeploymentのSwitch Overを利用することを推奨しており、Greenを手動でPromoteするとBlue/Green構成が壊れるため注意が必要です。
2. 📸 アップグレード前に手動スナップショットを取得する
Blue/Greenを利用しない場合でも、アップグレード前に手動スナップショットを取得しておくことは重要です。
アップグレード前
↓
手動スナップショット
↓
Auroraアップグレード
↓
問題発生
↓
スナップショットから新しいクラスターを作成
ただし、ここには重要な注意点があります。
スナップショットから復元すると、スナップショット取得後に発生したデータ変更は含まれません。
例えば、
10:00 スナップショット取得
10:30 アップグレード
11:00 アプリケーションからデータ更新
11:30 障害発生
という場合、10:00以降のデータをどのように扱うかを別途検討する必要があります。
したがって、スナップショットは、
「バージョンアップ前の状態を保存する最後の防波堤」
として考えるのがよいでしょう。
3. 🔄 互換性のあるバージョンへ段階的に復元・アップグレードする
目的のバージョンを直接指定できない場合、利用可能な互換バージョンを経由して段階的にアップグレードする方法も考えられます。
例えば、
旧バージョン
↓
復元可能なバージョン
↓
中間バージョン
↓
目的のバージョン
という形です。
ただし、任意のバージョンを中継できるわけではありません。
実際に利用可能なアップグレードパスや互換性をAWS側で確認する必要があります。
4. 🔁 ロジカルレプリケーションを利用する
より高度な構成として、ロジカルレプリケーションを利用して旧環境と新環境を同期させる方法もあります。
旧環境
Aurora PostgreSQL 16.x
│
│ Logical Replication
▼
新環境
Aurora PostgreSQL 17.x
新環境で十分な検証を行った後に切り替えることで、スナップショットだけに依存しない移行方式を構築できます。
ただし、ロジカルレプリケーションには制約があるため、対象DBエンジンや構成、使用している機能を事前に確認する必要があります。
Aurora Blue/Green Deploymentsでも内部的にレプリケーションを利用するため、特にAurora PostgreSQLでは論理レプリケーションに関する制約を事前確認することが重要です。
5. 🆘 RDS Extended Supportを利用する
サポート終了したメジャーバージョンを継続して利用する必要がある場合は、RDS Extended Supportも選択肢になります。
RDS Extended Supportを利用すると、Auroraの標準サポート終了後も、対象のメジャーバージョンを追加料金で継続利用できます。
ただし、ここは注意が必要です。
RDS Extended Supportを有効にすれば、任意の古いマイナーバージョンへ自由に復元できる、という意味ではありません。
Extended Supportの対象となるのは特定のバージョンです。
また、スナップショット復元時にはExtended Supportの設定によって動作が変わります。
例えば、標準サポート終了後のバージョンを復元する場合、Extended Supportを利用しない設定では、AWSがサポート対象の新しいバージョンへのアップグレードを試みる場合があります。
したがって、
「古いバージョンへ戻したいからExtended Supportを使えばよい」
と単純に判断するのではなく、対象のメジャー／マイナーバージョンがExtended Supportの対象になっているかを確認する必要があります。
6. 📞 upgrade-failed になった場合はAWS Supportへ相談する
Auroraのアップグレードが失敗すると、クラスターが
upgrade-failed
という状態になる場合があります。
この場合、Auroraは rds-final プレフィックスを使用した最終スナップショットを作成します。
AWS公式ドキュメントでは、アップグレード失敗後に非推奨バージョンで復元されたデータベースへアクセスする必要がある場合、AWS Supportへ問い合わせるよう案内されています。
そのため、
upgrade-failed
↓
rds-final スナップショット作成
↓
非推奨バージョンへのアクセスが必要
↓
AWS Supportへ問い合わせ
という流れになります。
このケースでは、自己判断で何度も復元・アップグレードを繰り返すより、AWS Supportへ相談した方が安全です。
どの方法を選ぶべきか？
目的別に整理すると、以下のようになります。
| 方法 | ロールバック性 | ダウンタイム | 特徴 |
|---|---|---|---|
| 🔵 Blue/Green | ◎ | 小 | 本番を残して新環境を検証できる |
| 📸 手動スナップショット | △ | あり得る | 最低限のバックアップとして有効 |
| 🔄 段階的アップグレード | △ | あり得る | 互換性のある経路が必要 |
| 🔁 ロジカルレプリケーション | ○ | 小さくできる | 高度な移行方式 |
| 🆘 RDS Extended Support | ○ | ― | 古いメジャーバージョンを継続利用 |
| 📞 AWS Support | ケースによる | ケースによる |
upgrade-failedなどの緊急時 |
結局、どうするのがよいのか？
本番環境のAuroraをアップグレードする場合、
「アップグレード前にスナップショットを取っておけば大丈夫」
とは考えない方が安全です。
特に、
スナップショット
↓
旧バージョンへ復元
というロールバック方式は、対象バージョンのサポート状況やAWS側での復元可否に左右されます。
そのため、重要な本番環境では、
┌─ 問題あり → Blueを維持
│
Blue（本番） ───┤
│
└─ Green（アップグレード・検証）
│
↓
問題なし
│
↓
Switch Over
というBlue/Greenを中心としたアップグレード戦略が有力です。
そして、Blue/Greenを利用する場合でも、アップグレード前の手動スナップショットは別途取得しておくことをおすすめします。
つまり、
Blue/Greenを第一のロールバック手段、スナップショットを最後のバックアップ手段として考える
という構成です。
まとめ
Auroraのバージョンアップでは、
「スナップショットがあるから、いつでもアップグレード前に戻れる」
とは限りません。
特に、サポート終了したバージョンはスナップショット復元に制約があります。
そのため、アップグレード前には、
- 対象バージョンのサポート期間を確認する
- 実際にスナップショットから目的のバージョンへ復元できるか確認する
- 手動スナップショットを取得する
- 本番環境ではBlue/Greenを検討する
- 必要に応じてロジカルレプリケーションを検討する
- サポート終了バージョンが必要ならRDS Extended Supportを確認する
-
upgrade-failedになった場合はAWS Supportへ相談する
といった準備が重要です。
「バックアップを取る」だけではなく、「そのバックアップから本当に戻れるのか」まで確認しておくことが、Auroraのバージョンアップでは重要です。
もしも、Greenに書き込みテストしたい場合
・Greenのスナップショットを取得してそのスナップショットに対して書き込みを実施する方法があるが、スナップショットは、マイナーバージョンの最新版となる為、戻せない可能性はある。
その場合は、新規で作成したものに対して中身を確認する。