Major version upgrade

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 runs analysis, pre-fixups, the upgrade, and post-steps with a single command; it can process multiple databases in sequence to shorten downtime. DBUA does the same with a guided interface. A full backup beforehand is mandatory.

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 performs the major version migration (16 -> 17) in place; --link mode shortens the time by creating hard links instead of copying files, but invalidates the old cluster. Statistics must be regathered after the migration.

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

From MySQL 8.x on, in-place major upgrades are supported: a server started with the new binaries automatically converts the data dictionary and system tables (the old separate mysql_upgrade step has been removed). Upgrade one major version at a time.

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 upgrades the instance in place to the new major version. The safer method is a side-by-side installation, then moving the databases with backup/restore and raising the compatibility level in a separate step.

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 })

A major upgrade in MongoDB has two phases: first all nodes' binaries are rolled to the new version, then, once the cluster is stable, the FCV is raised to the new version. You can move up only one major version at a time; FCV is managed separately for downgrade capability.

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

A Redis major version migration (6.x -> 7.x) is done by setting up a replica on the new version, letting it sync, and then promoting it to master; write downtime is thus reduced to almost zero. RDB files are compatible with later versions.

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 does not support skipping major versions with any method: both rolling upgrade and full-cluster restart only move to the next major (n -> n+1) and require the source to be on the last minor (e.g. 7.17). Indices created two majors earlier (e.g. in 6.x) cannot be opened in the new version; they must be rebuilt with _reindex before the migration (8.x can read them only in a limited way as read-only archive indices). Take a snapshot and resolve deprecation warnings before the migration.