DBAtlas · Atlas für Datenbankbetrieb

Major-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 führt Analyse, Pre-Fixups, Upgrade und Nacharbeiten mit einem einzigen Befehl aus; es kann mehrere Datenbanken nacheinander verarbeiten, um die Ausfallzeit zu verkürzen. DBUA macht dasselbe mit geführter Oberfläche. Ein vorheriges Vollbackup ist Pflicht.

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 führt die Migration auf eine neue Major-Version (16 -> 17) in place durch; der Modus --link verkürzt die Dauer, indem er Hardlinks statt Dateikopien anlegt, macht den alten Cluster aber unbrauchbar. Nach der Migration müssen die Statistiken neu erhoben werden.

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

Ab MySQL 8.x werden In-place-Major-Upgrades unterstützt: Ein mit den neuen Binärdateien gestarteter Server konvertiert Data Dictionary und Systemtabellen automatisch (der früher separate Schritt mysql_upgrade entfällt). Führe Upgrades jeweils nur um eine Major-Version durch.

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 aktualisiert die Instanz in place auf die neue Major-Version. Sicherer ist eine Side-by-side-Installation, danach die Datenbanken per Backup/Restore umziehen und den Kompatibilitätsgrad in einem separaten Schritt anheben.

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

Ein Major-Upgrade in MongoDB hat zwei Phasen: Zuerst werden die Binärdateien aller Knoten rollierend auf die neue Version gebracht, dann wird bei stabilem Cluster die FCV auf die neue Version angehoben. Es kann jeweils nur um eine Major-Version aufgestiegen werden; die FCV wird für die Downgrade-Fähigkeit separat verwaltet.

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

Eine Redis-Migration auf eine neue Major-Version (6.x -> 7.x) erfolgt, indem eine Replica mit der neuen Version aufgesetzt, synchronisiert und dann zum Master befördert wird; die Schreibunterbrechung sinkt so nahezu auf null. RDB-Dateien sind mit späteren Versionen kompatibel.

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 unterstützt mit keiner Methode das Überspringen von Major-Versionen: Sowohl Rolling Upgrade als auch Full-Cluster-Restart wechseln nur auf die nächste Major-Version (n -> n+1) und setzen voraus, dass die Quelle auf der letzten Minor-Version ist (z. B. 7.17). Indizes, die zwei Major-Versionen früher (z. B. in 6.x) angelegt wurden, lassen sich in der neuen Version nicht öffnen; sie müssen vor der Migration mit _reindex neu aufgebaut werden (8.x kann sie nur eingeschränkt als schreibgeschützte Archivindizes lesen). Erstelle vor der Migration einen Snapshot und behebe die Deprecation-Warnungen.

In DBAtlas öffnen →