DBAtlas · データベース運用アトラス

バージョンアップグレードウィザード

パッチかメジャーか、インプレースか移行か? アップグレードを段階的に計画する。各分岐で事前チェック、方法、アップグレード後の作業を扱う。本番環境に手を付ける前に、ここでリハーサルする。

どのような種類のアップグレードを行いますか?

パッチ/マイナーバージョン (同一メジャーバージョン内。例: 16.2 -> 16.4、または SQL Server の CU) はリスクが低く、通常はインプレースで行う。メジャーバージョン (例: 15 -> 16) ではデータ形式の変更を伴う場合があり、より慎重な計画が必要となる。

SELECT * FROM v$version;
SELECT patch_id, action, status FROM dba_registry_sqlpatch ORDER BY action_time DESC;
  • マイナーバージョン/パッチ (同一メジャーバージョン、CU)
  • メジャーバージョン (メジャーバージョンが変わる)
  • 違いが分からないので説明してほしい

パッチかメジャーか?

パッチ: メジャーバージョンは変わらない (16.2 -> 16.4)。データファイルの形式は変わらず、通常はバイナリの入れ替え + 再起動で済む。メジャー: メジャーバージョンが変わる (15 -> 16)。カタログ / 形式が変わる可能性があり、pg_upgrade / AutoUpgrade / ダンプ/リストアが必要で、アプリケーションの互換性をテストする必要がある。

  • パッチである (同じメジャーバージョン)
  • メジャーである (メジャーバージョンが変わる)

バックアップとロールバック計画は準備できているか?

パッチはリスクが低いとはいえ、すべてのアップグレードの鉄則は「まずフルバックアップ (可能ならスナップショットも)」である。問題が起きたときに戻れるポイントが必要。

  • はい、バックアップとロールバックは準備できている
  • いいえ、まだ

まずバックアップとロールバック計画

アップグレードを開始する前にセーフティネットを用意する。

パッチを適用する

同じメジャーバージョン内のパッチ。クラスタ全体にローリングで適用すると (レプリカから開始)、ダウンタイムを減らせる。

メジャーアップグレードの方法

主な方法は 2 つ: (1) インプレース: 既存のサーバー上で変換する (pg_upgrade、Oracle AutoUpgrade/DBUA、MySQL のインプレース)。高速だがロールバックが難しい。(2) 移行: 新バージョンで新しいサーバーを構築し、データを移動 (ダンプ / リストアまたはレプリケーションで) してから切り替える。より安全で、ダウンタイムは最小限。

  • まず準備 / 互換性チェックを実行する
  • インプレース
  • 新しいサーバーへの移行による (最小限のダウンタイム)

互換性 / 準備状況のチェック

アップグレードの前に、対象バージョンの警告を収集する: 削除された (非推奨の) 機能、無効なオブジェクト、互換性レベル。

-- AutoUpgrade analyze mode: java -jar autoupgrade.jar -config cfg -mode analyze
  • 出力に問題なし。続行する
  • 警告 / 非互換性がある

まず警告を修正する

アップグレードの前に、レポート内のすべての警告を解決する。そうしないと、アップグレードが途中で失敗したり、アプリケーションが動作しなくなったりする可能性がある。

インプレースでのメジャーアップグレード

既存のサーバー上で変換する。高速だが、ロールバックは通常バックアップからのリストアを意味するため、スナップショットは必須。

移行によるアップグレード (最小限のダウンタイム)

新バージョンで新しいサーバーを構築し、データを移動してから、短時間の切り替えで移行する。最も安全な方法で、旧システムはそのまま残る。

DBAtlas で開く →