MySQL 8.0 fim do suporte Magento deixou de ser apenas uma preocupação futura para lojas que mantêm o banco como parte invisível da infraestrutura. Uma migração mal planejada pode afetar catálogo, checkout, pedidos, integrações, relatórios e tarefas executadas pelo cron. Por isso, a decisão não deve ser tratada como uma simples troca de servidor.
O MySQL 8.0 chegou ao fim do suporte em 30 de abril de 2026. Depois dessa data, as linhas 2.4.7, 2.4.6, 2.4.5 e 2.4.4 não terão compatibilidade ou suporte para versões do MySQL lançadas posteriormente, conforme os requisitos oficiais do Adobe Commerce. Isso não significa que a loja pare automaticamente, mas torna necessário revisar a continuidade operacional e a combinação suportada de plataforma e banco.
MySQL 8.0 fim do suporte Magento: qual é o impacto?
Continuar usando uma instalação estável não produz necessariamente um erro imediato. O problema aparece na manutenção de médio prazo: atualizações do sistema operacional, exigências da hospedagem, correções do banco e upgrades do Magento passam a depender de uma combinação que pode não ter continuidade compatível.
Para instalações locais nas linhas 2.4.7, 2.4.6, 2.4.5 e 2.4.4, a Adobe recomenda migrar a infraestrutura para uma versão compatível do MariaDB, de acordo com a matriz oficial de requisitos. A palavra “compatível” é essencial: não se deve escolher a versão mais nova do MariaDB sem antes cruzá-la com o patch exato do Magento instalado.
O Adobe Commerce 2.4.9, por exemplo, foi testado com MariaDB 12.3 como versão recomendada e também com MariaDB 11.8. A Adobe informa que somente as combinações relacionadas em sua matriz recebem suporte, conforme os requisitos de sistema do Adobe Commerce. Se a operação também planeja atualizar a plataforma, vale consultar nosso checklist de requisitos do Adobe Commerce 2.4.9 antes de definir o banco de destino.
1. Identifique a versão real da plataforma e do banco
Não baseie a decisão apenas no painel da hospedagem ou no nome comercial do plano. Registre a edição, a versão completa do Magento, o mecanismo do banco e os componentes que acessam os dados diretamente.
php bin/magento --version
composer show magento/product-community-edition
composer show magento/product-enterprise-editionNo banco, execute uma consulta somente de leitura:
SELECT VERSION();Complete o inventário com sistema operacional, versão do PHP, tamanho do banco, quantidade de pedidos, horário de maior movimento, réplicas, ferramentas de backup e serviços externos com acesso SQL.
2. Consulte a matriz do patch exato
Duas lojas na linha 2.4.6 podem usar patches diferentes e não devem assumir automaticamente a mesma combinação de infraestrutura. Confirme a linha e o patch completo, verifique o MariaDB aceito e registre a fonte usada para aprovar a mudança.
Se a versão atual não oferecer um caminho adequado, pode ser necessário atualizar o Magento antes ou durante o projeto. Evite, porém, trocar plataforma, PHP, banco, mecanismo de busca e módulos de checkout na mesma janela sem uma homologação capaz de separar as causas de eventuais falhas.
3. Mapeie extensões e consultas incompatíveis
O núcleo do Magento utiliza sua camada de persistência, mas módulos e integrações podem executar SQL próprio. Procure especialmente por:
- consultas SQL incluídas diretamente em módulos personalizados;
- procedures, triggers, views e eventos criados fora do Magento;
- integrações de ERP, BI ou logística com acesso direto ao banco;
- relatórios que dependam de funções específicas do MySQL;
- rotinas que assumam determinado modo SQL, collation ou comportamento de tipos;
- ferramentas externas de replicação, auditoria e backup.
Uma extensão aparecer como habilitada não comprova sua compatibilidade. Consulte a documentação do fornecedor, revise o código personalizado e execute os fluxos que realmente gravam e consultam dados.
4. Prepare um backup restaurável
Backup só reduz o risco quando pode ser restaurado. Gere uma cópia consistente do banco, preserve o diretório de mídia, o código versionado, o arquivo de configuração e os segredos por um mecanismo seguro. Não exponha senhas na linha de comando ou em históricos do terminal.
Um ponto de partida para exportação lógica, ajustado à infraestrutura, pode incluir:
mysqldump --single-transaction --routines --triggers
--events --hex-blob NOME_DO_BANCO > backup.sqlEm bases grandes ou com escrita intensa, essa abordagem pode não ser suficiente para cumprir a janela disponível. Valide duração, espaço, consistência e tempo de restauração em homologação.
5. Reproduza a loja em homologação
A homologação deve se aproximar da produção em volume de catálogo, configuração, módulos e integrações. Anonimize dados pessoais quando necessário e impeça o envio acidental de e-mails, cobranças, webhooks e atualizações para sistemas reais.
Instale o MariaDB escolhido, importe a cópia e registre erros e avisos da restauração. Compare quantidade de tabelas, tamanho, mecanismos de armazenamento, charset, collation, usuários, privilégios, fuso horário e parâmetros relevantes. Não reutilize automaticamente a configuração do MySQL sem avaliar seu equivalente no destino.
6. Teste escrita, leitura e processamento assíncrono
A página inicial abrir não valida a migração. Execute um roteiro comercial completo:
- login, cadastro e recuperação de senha;
- busca, categoria, produto simples e configurável;
- carrinho, cupom, cálculo de frete e checkout;
- pagamento autorizado, criação de pedido, fatura e cancelamento;
- atualização de estoque e sincronização com ERP;
- importação e exportação de produtos;
- cron, consumidores de filas e relatórios;
- Admin, permissões e salvamento de configurações.
Depois da importação, acompanhe também os indexadores. Caso produtos, preços ou categorias fiquem desatualizados, use o roteiro para diagnosticar indexadores Magento 2 travados em vez de iniciar reindexações repetidas sem identificar a causa.
7. Compare desempenho antes de aprovar
Meça os mesmos cenários antes e depois da mudança. Observe tempo de consultas, CPU, memória, conexões, bloqueios, tamanho de tabelas temporárias, duração do cron e processamento de filas. Uma média isolada de carregamento não mostra gargalos em importações, promoções ou fechamento de pedidos.
Considere ainda o aquecimento de caches. Comparar um ambiente já aquecido com outro recém-restaurado pode produzir uma conclusão enganosa sobre o desempenho do banco.
8. Defina corte, reversão e responsáveis
O plano de produção deve indicar quem interrompe escritas, gera o backup final, importa os dados, altera a conexão, valida a aplicação e autoriza a reabertura. Defina também o ponto máximo para desistir da mudança e executar o rollback.
Durante a janela, impeça que pedidos sejam gravados simultaneamente nos bancos antigo e novo. Se o procedimento envolver deploy de código, consulte também o guia para recuperar o Magento 2 fora do ar após deploy e prepare verificações independentes para aplicação e banco.
9. Monitore a loja depois da migração
Após liberar o tráfego, acompanhe logs do Magento, PHP, servidor web e MariaDB. Verifique criação de pedidos, aprovações de pagamento, filas, indexação, integrações e tempo de resposta. Compare contagens operacionais com o padrão da loja, sem depender apenas de alertas de indisponibilidade.
Mantenha o ambiente anterior preservado pelo período definido na política da operação, mas bloqueado contra novas escritas e protegido contra acesso indevido. Documente parâmetros finais, testes executados e problemas encontrados para facilitar futuras atualizações.
Perguntas frequentes
Quais versões do Magento 2 são afetadas pelo fim do MySQL 8.0?
A orientação apresentada pela Adobe menciona as linhas 2.4.7, 2.4.6, 2.4.5 e 2.4.4. A compatibilidade deve ser conferida pelo patch completo, pois a matriz pode variar entre versões.
O Magento 2.4.6 funciona com MariaDB 10.11?
Não presuma compatibilidade apenas pela linha 2.4.6. Consulte na matriz oficial o patch exato instalado e use somente uma combinação relacionada para ele.
É necessário atualizar o Magento antes de migrar?
Depende da versão atual e do MariaDB pretendido. Em alguns projetos, atualizar primeiro reduz incompatibilidades; em outros, separar as mudanças facilita o diagnóstico. A decisão deve vir de uma matriz de compatibilidade e de testes em homologação.
Como saber se a migração foi concluída corretamente?
Além de validar a conexão, teste checkout, pedidos, estoque, cron, filas, indexadores, Admin e integrações. Monitore erros, consultas lentas e indicadores comerciais depois da liberação.
Conclusão
O tema MySQL 8.0 fim do suporte Magento exige uma decisão de continuidade, não uma troca apressada de tecnologia. Inventarie a instalação, selecione um MariaDB compatível, restaure uma cópia em homologação e valide os fluxos comerciais antes do corte.
Se sua equipe precisa revisar a compatibilidade, preparar a homologação ou executar a migração com um plano de reversão, fale com os especialistas em suporte Magento para avaliar o ambiente e organizar os próximos passos.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
