バージョンアップグレード / パッチのロールバック

症状

アップグレード/パッチ後の問題: 性能のリグレッション、アプリケーションの非互換、データベースがオープンしない。

1. まず立ち止まる: フォールバック計画はあるか

本番のアップグレード前にフルバックアップと (可能なら) ストレージスナップショットを取っていない場合、最も安全な道は前進して修正すること (fix forward) である。ほとんどのデータベースでは、ロールバックはバックアップからのリストアを意味する。このステップは本来アップグレード前に計画しておくべきものである。

2. 問題を分類する

オプティマイザの計画リグレッション (クエリが遅くなった) か、アプリケーション/ドライバーの非互換か、オープン不能/破損か。それにより解決の道筋は大きく異なる。

3. データベース別のロールバック方法

Oracle: datapatch によるパッチのロールバック、または Flashback Database (保証付きリストアポイントを作成していた場合)。PostgreSQL: pg_upgrade 後のロールバック = 旧バイナリ + 旧データディレクトリのバックアップ。MySQL: インプレースのダウングレードは一般にサポートされない — バックアップからリストアする。SQL Server: ダウングレードはない — アップグレード前のバックアップからリストアする。いずれの場合も、スナップショット/バックアップが保険である。

4. 計画のリグレッションの場合: ロールバックせずに修正する

通常、バージョン全体をロールバックする必要はなく、変わったのは計画だけである。

Oracle

ALTER SYSTEM SET optimizer_features_enable='19.1.0';  -- pin to the old behavior
-- or lock in the good plan with a SQL Plan Baseline

PostgreSQL

ANALYZE;  -- fresh statistics first
-- if needed, temporarily: steer the plan with settings such as SET enable_nestloop=off;

5. 恒久対策: 次回に向けて

まずステージングで実際のワークロードを使ってアップグレードをテストし、カナリア/ローリングアップグレードを適用し、保証付きリストアポイント / スナップショットを取り、フォールバック手順を文書化する。