RDSのアップグレードでBlue/Greenを推奨しているが…
実際にアップグレードするときは書き込みなどができない。更新の内容でよくあるのが、文字コードの変更だ。そうなると、文字コードの保証なく、更新できる出来ないの判断となり文字コードなんて細かく見ている暇はない。つまり、実際はNGかわからないままリリースし、失敗した場合24時間稼働のアプリケーション用のDBなどの場合スナップショットにも戻せない事態が発生しうる。そうなったらもう、戻すにはものすごい時間がかかり、新しいDBをしっかりと大丈夫だというところまで制御するのどっちが早いか微妙な状態になりえる
AWS公式が想定している失敗パターン
アップグレード失敗時の状態:
DBインスタンスが upgrade-failed ステータスになります
この状態では、以下の操作のみ可能です:
同じアップグレードの再試行
自動化の一時停止/再開(RDS Custom)
ポイントインタイムリカバリ(PITR)
DBインスタンスの削除
📋 文字コード問題への公式対応
アップグレード前の対処:
文字コード変更が必要な場合、Database Migration Assistant for Unicode (DMU) または export/import の使用が推奨されています
アプリケーションデータを含むインスタンスの文字セット変更には、これらのツールが必要です
レプリケーションツールの活用:
Oracle GoldenGate
AWS Database Migration Service (DMS)
これらを使用することで、ダウンタイムを最小限に抑えた移行が可能です
重要な注意点
公式ドキュメントでは、アップグレード後の文字コード問題によるロールバックは直接的には想定されていません。そのため:
事前検証が重要: ステージング環境での十分なテスト
Blue/Greenデプロイメント: 問題発生時に旧環境へ切り戻し可能
DMSによる並行移行: 新旧両環境を維持しながらデータ移行
現実的な対処法
アップグレード後に文字コード問題が発覚した場合:
アップグレード前の手動スナップショットから復元⇒データのリカバリはできるが、設定は復元できない。バージョンが最新になっているため、基本データリカバリでの利用くらいしかできない。
DMSで新しいDBインスタンスへデータ移行(文字コード変換含む)
アプリケーションの接続先を切り替え