O MySQL 8.0 Magento fim do suporte tornou-se um ponto importante de infraestrutura para lojas que ainda operam nas linhas 2.4.4, 2.4.5, 2.4.6 ou 2.4.7. O banco não deixa de funcionar automaticamente, mas permanecer nessa configuração pode limitar suporte, correções futuras e opções seguras de atualização.
A decisão não deve ser resumida a trocar MySQL por MariaDB diretamente em produção. É necessário conferir a edição e a versão exata do Magento, mapear extensões, testar consultas customizadas e preparar uma janela de migração que preserve pedidos, clientes e estoque.
O que significa o fim do suporte do MySQL 8.0 no Magento?
O MySQL 8.0 atingiu o fim do suporte em 30 de abril de 2026. A Adobe informa que, depois dessa data, as linhas Adobe Commerce 2.4.4, 2.4.5, 2.4.6 e 2.4.7 não terão compatibilidade nem suporte para versões principais do MySQL posteriores à 8.0, conforme os requisitos de sistema do Adobe Commerce.
Na prática, isso não significa que uma loja com MySQL 8.0 ficará indisponível de uma hora para outra. O serviço pode continuar iniciando e processando pedidos. O problema é operacional: o banco chegou ao fim de seu ciclo de suporte, enquanto instalar uma versão principal posterior sem compatibilidade declarada também não oferece um caminho seguro para essas linhas do Commerce.
Esse cenário cria uma combinação delicada. Continuar como está aumenta a dependência de uma tecnologia sem manutenção regular, mas atualizar apenas o banco pode colocar a aplicação em uma configuração não suportada. Por isso, a análise precisa considerar plataforma, banco, PHP, mecanismo de busca e extensões como um conjunto.
Quais lojas precisam revisar a infraestrutura?
A revisão é especialmente necessária para operações que apresentam uma ou mais destas condições:
- Magento ou Adobe Commerce nas linhas 2.4.4 a 2.4.7;
- ambiente próprio, servidor dedicado, VPS ou nuvem administrada pela equipe da loja;
- MySQL 8.0 instalado diretamente ou fornecido como serviço gerenciado;
- extensões que executam consultas SQL próprias;
- integrações que leem ou escrevem diretamente no banco;
- réplicas, rotinas de backup ou relatórios dependentes do MySQL;
- projeto de atualização adiado por incompatibilidade de módulos.
O primeiro passo é confirmar os componentes reais, sem confiar apenas em uma documentação antiga do projeto. A versão do banco pode ser consultada com mysql --version ou por uma consulta administrativa equivalente. Para a aplicação, use php bin/magento --version e confira também os pacotes instalados no composer.lock.
Se o inventário revelar módulos bloqueando a evolução da plataforma, vale tratar essa dependência antes da migração. O guia sobre erro no Composer Magento mostra como identificar pacotes incompatíveis sem alterar o core.
Migrar para MariaDB ou atualizar primeiro o Magento?
Não existe uma resposta única. A Adobe recomenda que clientes on-premises do Adobe Commerce nas linhas 2.4.4, 2.4.5, 2.4.6 e 2.4.7 migrem os servidores de banco para uma versão compatível do MariaDB, segundo a mesma página de requisitos oficiais de sistema. A palavra decisiva é “compatível”: a versão do MariaDB precisa ser validada contra a linha e o patch exatos da aplicação.
Também não é prudente escolher automaticamente o MariaDB 10.6 apenas porque ele aparece em matrizes de versões anteriores. A política de ciclo de vida da Adobe lista o fim de suporte do MariaDB 10.6 em julho de 2026 para determinadas linhas antigas, tornando indispensável verificar a combinação completa antes de definir o destino da migração, conforme a FAQ oficial sobre estratégia de releases e ciclo de vida.
Quando priorizar a atualização da plataforma
Atualizar o Magento primeiro, ou incluir a atualização no mesmo projeto, tende a ser mais coerente quando a versão atual está próxima do fim de seu próprio ciclo, a infraestrutura já precisa de modernização ou a empresa quer evitar duas grandes intervenções em pouco tempo.
Essa opção exige uma auditoria mais ampla de PHP, Composer, OpenSearch, tema, checkout, meios de pagamento e integrações. Para equipes avaliando uma linha mais nova, o artigo sobre o planejamento da atualização para Magento 2.4.9 ajuda a dimensionar esse trabalho.
Quando uma migração de banco isolada pode fazer sentido
A migração isolada pode ser considerada quando a aplicação ainda está em uma linha mantida, há uma combinação de MariaDB oficialmente compatível e o upgrade completo exige um projeto mais longo. Mesmo assim, ela deve ser tratada como uma etapa planejada, não como solução definitiva para uma instalação legada.
Checklist para migrar sem perder pedidos
- Faça o inventário técnico: registre edição, versão e patch do Magento, banco atual, PHP, módulos, integrações, réplicas e serviços gerenciados.
- Consulte a matriz oficial: confirme a versão de MariaDB suportada pela combinação exata da aplicação. Não use apenas a versão principal do Magento como referência.
- Audite acessos diretos ao banco: procure relatórios, ERPs, hubs, scripts de estoque e extensões que contornem as APIs do Magento.
- Crie backup verificável: preserve banco, arquivos, mídia, configuração e chaves necessárias. Um backup só é confiável depois que sua restauração foi testada.
- Monte um staging representativo: use uma cópia sanitizada e recente, com volume de catálogo e pedidos suficiente para reproduzir consultas pesadas.
- Teste a restauração no banco de destino: valide codificação, collation, usuários, privilégios, procedures, triggers e parâmetros de conexão.
- Execute os fluxos comerciais: teste login, carrinho, cupom, frete, pagamento, criação de pedido, faturamento, cancelamento e reembolso.
- Valide tarefas assíncronas: revise cron, consumidores de filas, indexadores, exportações, importações e sincronização com sistemas externos.
- Meça desempenho: compare tempo de consultas, carga do banco, páginas de categoria, busca, painel administrativo e processamento de pedidos.
- Prepare rollback: estabeleça critérios objetivos para interromper a virada e retornar ao ambiente anterior sem aceitar novos pedidos em dois bancos diferentes.
Como organizar a virada de produção
Na janela de migração, a loja deve entrar em manutenção antes do backup final para impedir alterações concorrentes. Depois da restauração, atualize a conexão de forma controlada, limpe apenas os caches necessários e verifique o estado da aplicação com comandos como php bin/magento setup:db:status e php bin/magento indexer:status.
Antes de reabrir, crie um pedido controlado e confirme sua presença no painel, no banco e nas integrações. Monitore logs da aplicação, PHP, servidor web e banco. Filas represadas, indexadores atrasados e erros de conexão podem aparecer mesmo quando a página inicial abre normalmente.
Evite executar alterações improvisadas de schema ou editar tabelas para “forçar” a compatibilidade. O banco Magento contém relações importantes entre pedidos, clientes, catálogo, estoque e índices. Uma correção aparentemente simples pode produzir inconsistências que só surgem dias depois.
Conclusão: trate o banco como parte do ciclo do Magento
O cenário de MySQL 8.0 Magento fim do suporte não pede pânico, mas também não deve ser ignorado. A loja pode continuar funcionando, porém passa a depender de uma combinação tecnológica com opções limitadas de suporte e evolução.
O caminho seguro é identificar a versão real do ambiente, consultar a matriz oficial, escolher entre migração compatível e upgrade da plataforma e ensaiar todo o procedimento em staging. Se sua equipe precisa avaliar dependências, riscos e janela de manutenção, um diagnóstico técnico especializado pode transformar essa mudança em um projeto controlado, em vez de uma intervenção emergencial.
Perguntas frequentes
Minha loja Magento 2.4.6 pode continuar usando MySQL 8.0?
Ela não para automaticamente por causa do fim do suporte. Entretanto, continuar nessa configuração traz riscos de manutenção e não autoriza instalar uma versão principal posterior do MySQL sem compatibilidade declarada. Avalie uma versão compatível do MariaDB ou um projeto de atualização da plataforma.
É melhor migrar para MariaDB ou atualizar primeiro o Magento?
Depende da linha, do patch, das extensões e da infraestrutura. Se a aplicação também estiver perto do fim de seu ciclo, um upgrade coordenado pode evitar duas migrações. Se ainda houver uma combinação suportada, a troca isolada do banco pode funcionar como etapa intermediária.
Como testar a migração sem perder pedidos?
Restaure uma cópia recente em staging, teste todos os fluxos e planeje uma janela de manutenção para o backup final. Durante a virada, impeça novas gravações até o banco de destino estar validado e mantenha um plano de rollback.
Quais extensões podem ser afetadas?
Principalmente módulos com SQL próprio, relatórios, integrações que acessam tabelas diretamente, rotinas de importação e sistemas externos que dependem de recursos específicos do MySQL. O inventário deve ser feito antes da migração.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
