メジャーバージョンアップグレード

Oracle

# Recommended: AutoUpgrade (analyze + fixups + deploy in a single flow):
$ java -jar $NEW_ORACLE_HOME/rdbms/admin/autoupgrade.jar -config db.cfg -mode deploy
# Graphical alternative: DBUA (Database Upgrade Assistant)
$ $NEW_ORACLE_HOME/bin/dbua

AutoUpgrade は分析、事前修正、アップグレード、事後処理を単一のコマンドで実行する。複数のデータベースを順に処理してダウンタイムを短縮できる。DBUA は同じ処理をガイド付きインターフェースで行う。事前のフルバックアップは必須。

PostgreSQL

# pg_upgrade to the new major version (with both clusters stopped):
$ pg_upgrade \
    --old-datadir=/var/lib/pgsql/16/data \
    --new-datadir=/var/lib/pgsql/17/data \
    --old-bindir=/usr/pgsql-16/bin \
    --new-bindir=/usr/pgsql-17/bin \
    --link   # fast migration with hard links
# Then gather statistics (analyze_new_cluster.sh was removed in PG14):
$ vacuumdb --all --analyze-in-stages

pg_upgrade はメジャーバージョンの移行(16 -> 17)をインプレースで行う。--link モードはファイルをコピーせずにハードリンクを作成して時間を短縮するが、旧クラスタは使用不能になる。移行後は統計を再収集する必要がある。

MySQL

# In-place upgrade (same datadir, new binaries):
$ sudo systemctl stop mysqld
$ sudo dnf install mysql-community-server-8.4   # replacing the old package
$ sudo systemctl start mysqld   # the server upgrades the dictionary automatically

MySQL 8.x 以降はインプレースのメジャーアップグレードがサポートされる。新しいバイナリで起動したサーバーがデータディクショナリとシステムテーブルを自動的に変換する(旧来の個別の mysql_upgrade 手順は削除された)。メジャーバージョンは 1 つずつアップグレードする。

SQL Server

-- In-place major version upgrade (with setup):
-- setup.exe /q /ACTION=upgrade /INSTANCENAME=MSSQLSERVER
--   /IAcceptSQLServerLicenseTerms
-- Alternative: install a new instance side by side and move the databases (restore/attach).

setup /ACTION=upgrade はインスタンスを新しいメジャーバージョンにインプレースでアップグレードする。より安全な方法は、サイドバイサイドでインストールし、バックアップ/リストアでデータベースを移行して、互換性レベルを別の手順で引き上げること。

MongoDB

// Stepwise major upgrade (e.g. 6.0 -> 7.0), one major version at a time:
// 1) Roll the binary to 7.0 on all nodes
// 2) Once the cluster is stable, raise the FCV:
db.adminCommand({ setFeatureCompatibilityVersion: "7.0", confirm: true })

MongoDB のメジャーアップグレードは 2 段階。まず全ノードのバイナリを新バージョンにローリングで更新し、クラスタが安定したら FCV を新バージョンに引き上げる。一度に上げられるメジャーバージョンは 1 つのみ。ダウングレードに備えて FCV は個別に管理される。

Redis

# Major upgrade via a replica (no downtime):
# 1) Create a replica on the new version, wait for full sync from the master
# 2) Prepare the application; fail over the master:
redis-cli -h <new-replica> REPLICAOF NO ONE   # make the new version the master
# 3) Upgrade the old master, attach it as a replica of the new master

Redis のメジャーバージョン移行(6.x -> 7.x)は、新バージョンでレプリカを構築して同期させ、それを master に昇格させることで行う。これにより書き込みのダウンタイムはほぼゼロに抑えられる。RDB ファイルは後のバージョンと互換性がある。

Elasticsearch

# Major versions cannot be skipped; one major at a time, via the last minor first (e.g. 6.8 -> 7.17 -> 8.x):
# 1) Upgrade to the last minor (7.17), resolve the GET _migration/deprecations warnings
# 2) Rolling upgrade, per node: set allocation to "primaries" -> update the node -> start -> wait for green
# Alternative: full-cluster restart (stop all nodes -> upgrade -> start together); this also moves only one major

Elasticsearch はいかなる方法でもメジャーバージョンの飛び越しをサポートしない。ローリングアップグレードもクラスタ全体の再起動も次のメジャー(n -> n+1)にのみ移行でき、ソースは最後のマイナー(例: 7.17)である必要がある。2 つ前のメジャー(例: 6.x)で作成されたインデックスは新バージョンで開けないため、移行前に _reindex で再構築する必要がある(8.x では読み取り専用のアーカイブインデックスとして限定的にのみ読める)。移行前にスナップショットを取得し、非推奨の警告を解決すること。

DBAtlas で開く →