DBAtlas · Atlas de operações de banco de dados

Upgrade de versão major

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

O AutoUpgrade executa a análise, os pre-fixups, o upgrade e as etapas posteriores com um único comando; pode processar vários bancos em sequência para reduzir o downtime. O DBUA faz o mesmo com uma interface guiada. Um backup completo prévio é obrigatório.

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 faz a migração de versão major (16 -> 17) in-place; o modo --link reduz o tempo criando hard links em vez de copiar arquivos, mas invalida o cluster antigo. As estatísticas devem ser coletadas novamente após a migração.

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 do MySQL 8.x, upgrades major in-place são suportados: um servidor iniciado com os novos binários converte automaticamente o data dictionary e as tabelas de sistema (a antiga etapa separada de mysql_upgrade foi removida). Faça o upgrade de uma versão major por 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 atualiza a instância in-place para a nova versão major. O método mais seguro é uma instalação side-by-side, movendo depois os bancos com backup/restore e elevando o compatibility level em uma etapa separada.

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

Um upgrade major no MongoDB tem duas fases: primeiro os binários de todos os nós são atualizados de forma rolling para a nova versão; depois, com o cluster estável, o FCV é elevado para a nova versão. Só é possível subir uma versão major por vez; o FCV é gerenciado separadamente para permitir 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

A migração de versão major do Redis (6.x -> 7.x) é feita configurando uma réplica na nova versão, deixando-a sincronizar e depois promovendo-a a master; assim, o downtime de escrita fica próximo de zero. Os arquivos RDB são compatíveis com versões 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

O Elasticsearch não permite pular versões major por nenhum método: tanto o rolling upgrade quanto o full-cluster restart só avançam para a próxima major (n -> n+1) e exigem que a origem esteja na última minor (ex.: 7.17). Índices criados duas majors antes (ex.: no 6.x) não podem ser abertos na nova versão; devem ser reconstruídos com _reindex antes da migração (o 8.x só consegue lê-los de forma limitada, como archive indices somente leitura). Faça um snapshot e resolva os avisos de obsolescência antes da migração.

Abrir no DBAtlas →