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

Assistente de upgrade de versão

Patch ou major, no local ou por migração? Planeje o upgrade passo a passo; cada ramo cobre as verificações prévias, o método e o trabalho pós-upgrade. Ensaie aqui antes de mexer na produção.

Que tipo de upgrade você está fazendo?

Uma versão de patch/minor (dentro da mesma versão major, por exemplo, 16.2 -> 16.4, ou um CU do SQL Server) tem baixo risco e geralmente é feita in-place. Uma versão major (por exemplo, 15 -> 16) pode envolver mudanças no formato dos dados e exige um planejamento mais cuidadoso.

SELECT * FROM v$version;
SELECT patch_id, action, status FROM dba_registry_sqlpatch ORDER BY action_time DESC;
  • Versão minor / patch (mesma versão major, CU)
  • Versão major (a versão major muda)
  • Não sei a diferença; explique

Patch ou major?

Patch: a versão major continua a mesma (16.2 -> 16.4); o formato dos datafiles não muda, geralmente basta trocar os binários + restart. Major: a versão major muda (15 -> 16); o catálogo/formato pode mudar, é necessário pg_upgrade / AutoUpgrade / dump-restore, e a compatibilidade da aplicação precisa ser testada.

  • O meu é um patch (mesma versão major)
  • O meu é um major (a versão major muda)

Seu backup e seu plano de rollback estão prontos?

Mesmo que um patch seja de baixo risco, a regra de ouro de todo upgrade é: backup completo primeiro (e um snapshot, se possível). Você precisa de um ponto para onde voltar se algo der errado.

  • Sim, backup + rollback estão prontos
  • Não, ainda não

Primeiro, backup + plano de rollback

Monte a rede de segurança antes de iniciar o upgrade.

Aplicar o patch

Um patch dentro da mesma versão major. Aplicá-lo de forma rolling em um cluster (começando pelas réplicas) reduz o downtime.

Método de upgrade major

Dois caminhos principais: (1) No local: converter no servidor existente (pg_upgrade, Oracle AutoUpgrade/DBUA, MySQL in-place). Rápido, mas difícil de reverter. (2) Por migração: montar um servidor novo na nova versão, mover os dados (com dump/restore ou replicação) e depois fazer o cutover. Mais seguro, com downtime mínimo.

  • Quero fazer uma verificação de preparação/compatibilidade primeiro
  • No local
  • Migrando para um novo servidor (downtime mínimo)

Verificação de compatibilidade / prontidão

Antes do upgrade, colete os avisos da versão de destino: recursos removidos (obsoletos), objetos inválidos, nível de compatibilidade.

-- AutoUpgrade analyze mode: java -jar autoupgrade.jar -config cfg -mode analyze
  • Saída limpa, continuar
  • Há avisos/incompatibilidades

Corrija os avisos primeiro

Resolva todos os avisos do relatório ANTES do upgrade; caso contrário, o upgrade pode falhar no meio ou a aplicação pode quebrar.

Upgrade major no local

Converter no servidor existente. Rápido, mas o rollback geralmente significa restaurar a partir do backup, então um snapshot é obrigatório.

Upgrade por migração (downtime mínimo)

Monte um servidor novo na nova versão, mova os dados e depois troque com um cutover curto. O método mais seguro; o sistema antigo permanece intacto.

Abrir no DBAtlas →