Mise à niveau de version majeure

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 exécute l'analyse, les pre-fixups, la mise à niveau et les post-étapes en une seule commande ; il peut traiter plusieurs bases à la suite pour réduire l'interruption. DBUA fait de même avec une interface guidée. Une sauvegarde complète préalable est obligatoire.

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 effectue la migration de version majeure (16 -> 17) sur place ; le mode --link réduit la durée en créant des liens physiques au lieu de copier les fichiers, mais rend l'ancien cluster inutilisable. Les statistiques doivent être recollectées après la 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

À partir de MySQL 8.x, les mises à niveau majeures sur place sont prises en charge : un serveur démarré avec les nouveaux binaires convertit automatiquement le dictionnaire de données et les tables système (l'ancienne étape séparée mysql_upgrade a été supprimée). Montez d'une version majeure à la fois.

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 met à niveau l'instance sur place vers la nouvelle version majeure. La méthode la plus sûre est une installation côte à côte, puis le déplacement des bases par backup/restore et l'élévation du niveau de compatibilité dans une étape distincte.

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

Une mise à niveau majeure MongoDB se fait en deux phases : d'abord les binaires de tous les nœuds passent en rolling à la nouvelle version, puis, une fois le cluster stable, la FCV est élevée à la nouvelle version. On ne peut monter que d'une version majeure à la fois ; la FCV est gérée séparément pour permettre un retour arrière.

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

Une migration de version majeure Redis (6.x -> 7.x) se fait en installant un réplica sur la nouvelle version, en le laissant se synchroniser, puis en le promouvant master ; l'interruption des écritures est ainsi réduite quasiment à zéro. Les fichiers RDB sont compatibles avec les versions ultérieures.

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 ne permet par aucune méthode de sauter des versions majeures : le rolling upgrade comme le redémarrage complet du cluster ne passent qu'à la majeure suivante (n -> n+1) et exigent que la source soit sur la dernière mineure (par ex. 7.17). Les indices créés deux majeures plus tôt (par ex. en 6.x) ne peuvent pas être ouverts dans la nouvelle version ; ils doivent être reconstruits avec _reindex avant la migration (8.x ne peut les lire que de façon limitée, comme archive indices en lecture seule). Prenez un snapshot et traitez les avertissements de dépréciation avant la migration.