O MySQL 8.0 chegou ao fim de vida em abril de 2026. A própria Oracle registra a versão 8.0.46 como o encerramento da série e orienta usuários a migrarem para o MySQL 8.4 LTS ou para a trilha Innovation. Para a maioria das aplicações de negócio, o 8.4 LTS é a escolha previsível: mantém uma linha estável e recebe correções dentro do ciclo de suporte.
Essa data muda a natureza do risco. Uma instância 8.0 pode continuar funcionando por anos, servindo WordPress, Laravel, integrações internas e bancos auxiliares. O problema é que funcionamento e manutenção deixaram de andar juntos. No modelo de Sustaining Support da Oracle, permanecem acessíveis correções já existentes, documentação e conhecimento acumulado. Novas atualizações, alertas de segurança e critical patch updates não fazem parte dessa fase.
O banco não vai falhar porque o calendário virou. A equipe só perdeu uma opção importante para quando a próxima falha aparecer.
O risco costuma estar fora da instância principal
É fácil localizar o banco da aplicação mais importante. Ele tem monitoramento, backup e alguém que recebe alertas. O inventário difícil está nos ambientes que quase não mudam: homologações antigas, réplicas usadas por relatórios, containers copiados de um docker-compose.yml, servidores de clientes e ferramentas internas mantidas por conveniência.
Executar mysql --version resolve uma parte pequena. A versão do cliente pode diferir da versão do servidor, e serviços gerenciados escondem a manutenção atrás do painel do provedor. O levantamento precisa registrar ao menos o endpoint, a edição, a versão do servidor, quem aplica patches, o dono da carga e o caminho de restauração. Em serviço gerenciado, vale pedir a política do fornecedor em vez de presumir que "gerenciado" significa "suportado".
Também convém separar criticidade de visibilidade. Um banco pequeno pode sustentar autenticação, faturamento ou uma fila de integração. Volume baixo não reduz automaticamente o dano de uma parada ou de dados incorretos.
Eu trataria a descoberta como uma busca por dependências. Repositórios, manifests de infraestrutura, configurações de CI, painéis de hospedagem e conexões salvas pela equipe apontam para lugares diferentes. O resultado útil é uma lista com responsáveis e decisões, sem virar um catálogo sem data de saída.
O caminho oficial é o 8.4 LTS, com teste
A documentação do MySQL 8.4 aceita a preparação de servidores 8.0 para a atualização. A Oracle recomenda executar o Upgrade Checker do MySQL Shell, revisar mudanças da versão, testar a aplicação, comparar desempenho, validar backup e realizar um teste final antes da produção.
O checker automatiza verificações relevantes e também indica pontos que precisam de análise manual. Ele consegue procurar variáveis removidas no arquivo de configuração e incompatibilidades conhecidas no servidor. Isso ajuda a substituir a pergunta vaga "será que quebra?" por uma lista reproduzível, mas não conhece o comportamento da sua aplicação.
Queries geradas por ORM, jobs raros, relatórios de fechamento e rotinas administrativas precisam entrar no ensaio. O conjunto de testes habitual pode cobrir regras de negócio e ainda ignorar plano de execução, tempo de lock, consumo de memória ou diferenças de collation. Uma cópia representativa dos dados e um replay de carga valem mais que subir um banco vazio e confirmar que a aplicação abriu a tela inicial.
Há outro detalhe operacional: a documentação alerta que voltar do 8.4 para uma versão anterior não é um downgrade simples no lugar. A alternativa segura depende de um backup anterior ou de uma estratégia lógica e de replicação preparada para esse fim. "Se der problema, voltamos" só existe depois que alguém demonstrou a restauração e mediu quanto ela demora.
Uma migração pequena ainda precisa de janela e saída
Para uma aplicação isolada, o plano pode caber em poucos passos concretos:
- identificar servidor, clientes, réplicas e consumidores;
- executar o Upgrade Checker e resolver os bloqueios;
- restaurar um backup recente em 8.4 e rodar testes com carga representativa;
- medir queries críticas e procedimentos de backup;
- definir a janela, o critério de abortar e a forma de restauração;
- atualizar a produção e observar erros, locks, latência e replicação.
Cada item deve produzir evidência. "Backup configurado" não prova que a restauração funciona. "Testes verdes" não mostra que o job mensal foi executado. "Sem erro no log" diz pouco sobre uma query que passou de 80 milissegundos para quatro segundos.
Em topologias maiores, o mesmo raciocínio ganha detalhes: compatibilidade entre versões durante a transição, ordem das réplicas, failover e atraso de replicação. Não é necessário criar uma arquitetura nova só para a migração. É necessário saber qual componente assume a carga se o passo seguinte falhar.
Adiar também é uma decisão de engenharia
Pode haver motivos reais para não migrar nesta semana. Um fornecedor ainda não certificou o 8.4, a equipe está numa janela comercial sensível ou o restore leva mais tempo do que o negócio aceita. Nesse caso, o adiamento precisa ter dono, prazo e mitigação.
Algumas medidas reduzem exposição enquanto a atualização não acontece: restringir rede, revisar credenciais, acompanhar divulgações de vulnerabilidades, aumentar a atenção a logs e reduzir serviços desnecessários. Nenhuma delas devolve ao MySQL 8.0 a produção de novos patches oficiais. Elas compram tempo e deveriam vir acompanhadas da data em que esse tempo acaba.
O EOL transforma dívida conhecida em dependência sem manutenção ativa. Antes de discutir a janela perfeita, eu procuraria a instância esquecida. Ela costuma ser a parte do plano que decide o prazo de verdade.
