Upgrade do MySQL 8.0 → 8.4 LTS (in-place)

Faz o upgrade de um MySQL 8.0 instalado para o 8.4 LTS no mesmo servidor (in-place): servidor único, source + réplicas (primeiro as réplicas, por último o source) ou InnoDB Cluster (Router → Shell → metadata → secondaries um a um → por último o primary). Inclui a verificação prévia util.checkForServerUpgrade em cada servidor, as variáveis removidas no 8.4 e o mysql_native_password desabilitado por padrão, ponto de retorno com cópia a frio, verificação e runbook de retorno ao 8.0. Como o downgrade não é suportado, o único caminho de volta é a cópia feita antes do upgrade. Para migrar movendo para novos servidores (dump/load), use o modo "Migrar para outro servidor" do guia de backup lógico.

Topologia: 1 servidor, source + réplicas ou InnoDB Cluster (3+ membros + servidores do MySQL Router)

Antes de começar

• O(s) servidor(es) está(ão) na última versão secundária do MySQL 8.0 (8.0.4x), instalado(s) a partir do repositório oficial do MySQL. O upgrade direto do 8.0 para o 8.4 é suportado; do 5.7 direto para o 8.4 não é suportado (passe antes pelo 8.0).
• Há espaço livre em … igual ao tamanho do diretório de dados + binlogs (para a cópia a frio).
• Há um backup recente bem-sucedido (XtraBackup 8.0 ou mysqldump) e um teste de restore. Depois do upgrade é preciso passar para o XtraBackup 8.4 (a versão 8.0 não faz backup de um servidor 8.4).
• O suporte da aplicação e dos drivers dos clientes (JDBC, PHP mysqlnd, Python…) ao MySQL 8.4 e ao caching_sha2_password foi verificado em ambiente de teste.
• A janela de manutenção está aprovada…; o tráfego de leitura pode cair porque as réplicas são atualizadas uma a uma, e há indisponibilidade de escrita durante o upgrade do source….
• A retenção de binlogs no source é maior que o tempo de upgrade das réplicas (os binlogs que as réplicas paradas ainda precisam não podem ser apagados).
• O cluster está saudável: todos os membros ONLINE, modo single-primary; o primeiro membro do formulário é o primary atual. Não inicie o upgrade com um membro RECOVERING ou com status OK_PARTIAL / OK_NO_TOLERANCE.
• A conta de administração do cluster … consegue se conectar a todos os membros pela porta … e a senha é conhecida (o MySQL Shell pede a senha em cada conexão).
• Nos servidores do Router, o MySQL Router está instalado a partir do repositório oficial do MySQL e roda como serviço systemd (mysqlrouter). Se o tráfego da aplicação passa por vários Routers, eles são atualizados um a um.
• A aplicação se conecta apenas pelo Router (uma aplicação que se conecta direto ao nome de um membro não consegue gravar quando o papel de primary muda).

Fases do guia

• Verificação prévia — Estado atual · Adicionar o repositório 8.4 e instalar o MySQL Shell 8.4 · Executar o Upgrade Checker · Procurar na configuração as variáveis removidas · Migrar as contas mysql_native_password
• Verificação prévia do InnoDB Cluster — Registrar o estado do cluster e os Routers · Verificar se é preciso upgrade da metadata (dryRun)
• Upgrade da metadata — Executar dba.upgradeMetadata()
• Preparação para a troca do primary — Verificar se os secondaries estão no 8.4 e ONLINE
• Verificação final do InnoDB Cluster — Verificar o status estendido do cluster · Devolver o papel de primary ao primeiro membro
• Após o upgrade — Verificar a replicação (…) · Passar o XtraBackup para o 8.4 e fazer um novo backup full · Migrar as contas mysql_native_password (solução definitiva) · Decidir quando apagar a cópia de retorno
• Retorno (volta ao 8.0) — Retorno: parar o 8.4 e tirar o diretório de dados do lugar · Retorno: parar o 8.4 e tirar o diretório de dados do lugar · Retorno: voltar ao software 8.0 · Retorno: voltar ao software 8.0 · Retorno: restaurar a cópia a frio · Retorno: restaurar a cópia a frio …