Actualización de versión mayor

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 ejecuta el análisis, los pre-fixups, la actualización y los pasos posteriores con un solo comando; puede procesar varias bases de datos en secuencia para acortar la indisponibilidad. DBUA hace lo mismo con una interfaz guiada. Es obligatorio un backup completo previo.

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 realiza la migración de versión mayor (16 -> 17) in situ; el modo --link acorta el tiempo creando hard links en lugar de copiar archivos, pero invalida el clúster antiguo. Las estadísticas deben recopilarse de nuevo tras la migración.

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

A partir de MySQL 8.x se admiten actualizaciones mayores in situ: un servidor arrancado con los nuevos binarios convierte automáticamente el diccionario de datos y las tablas del sistema (se eliminó el antiguo paso mysql_upgrade aparte). Actualice una versión mayor cada vez.

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 actualiza la instancia in situ a la nueva versión mayor. El método más seguro es una instalación en paralelo (side-by-side), mover después las bases de datos con backup/restore y subir el nivel de compatibilidad en un paso aparte.

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

Una actualización mayor en MongoDB tiene dos fases: primero se pasan los binarios de todos los nodos a la nueva versión y luego, con el clúster estable, se sube el FCV a la nueva versión. Solo se puede subir una versión mayor cada vez; el FCV se gestiona por separado para conservar la posibilidad de downgrade.

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

Una migración de versión mayor de Redis (6.x -> 7.x) se hace montando una réplica en la nueva versión, dejando que se sincronice y promoviéndola después a master; así la indisponibilidad de escritura se reduce casi a cero. Los archivos RDB son compatibles con versiones posteriores.

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 no admite saltarse versiones mayores con ningún método: tanto el rolling upgrade como el full-cluster restart solo pasan a la siguiente mayor (n -> n+1) y requieren que el origen esté en la última menor (p. ej., 7.17). Los índices creados dos versiones mayores antes (p. ej., en 6.x) no se pueden abrir en la nueva versión; deben reconstruirse con _reindex antes de la migración (8.x solo puede leerlos de forma limitada como archive indices de solo lectura). Tome un snapshot y resuelva las advertencias de obsolescencia antes de la migración.