Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
O fim do ciclo de vida (EOL) do MySQL é um dos eventos mais importantes e mais adiados no gerenciamento de bancos de dados corporativos. O MySQL é a base de plataformas de comércio eletrônico, aplicativos SaaS, sistemas de gerenciamento de conteúdo, ferramentas internas e pipelines de dados em praticamente todos os setores. Essa onipresença é exatamente o que torna o gerenciamento de seu ciclo de vida tão importante e tão fácil de adiar até que se torne urgente.
Mas as versões do MySQL não envelhecem bem por conta própria. Cada uma tem um período de suporte definido e, quando esse período termina, a Oracle deixa de lançar patches de segurança para ela. Todas as vulnerabilidades CVE divulgadas após esse ponto se aplicam à sua versão, mas nenhuma das correções mais é fornecida. Se você estiver usando o MySQL 5.7, o fim do suporte (EOL) do MySQL ocorreu em outubro de 2023. Se estiver usando o MySQL 8.0, ele ocorrerá em abril de 2026, e essa data está mais próxima do que a maioria das equipes imagina.
Esta publicação explica como funciona, na prática, o ciclo de vida das versões do MySQL, o que significa o EOL do MySQL em termos concretos de segurança e conformidade, e quais são suas opções quando uma atualização não é algo que você possa simplesmente agendar para o próximo sprint.
Principais conclusões
- As dependências ampliam a área de risco relacionada ao fim da vida útil (EOL) do MySQL: O MySQL inclui bibliotecas C de terceiros, como OpenSSL, curl, LZ4, zlib e outras, cada uma com sua própria exposição a vulnerabilidades CVE, que deixam de receber correções assim que a versão do MySQL chega ao fim da vida útil.
- Atualizações precipitadas são caras: As atualizações de versão principal do MySQL envolvem verificação de compatibilidade de esquema, testes de consultas de aplicativos, reconfiguração da replicação e implementações coordenadas em todo o parque de servidores. O custo de engenharia de uma migração não planejada raramente é insignificante.
- O fim do suporte (EOL) do MySQL não significa o fim da segurança. O Endless Lifecycle Support (ELS) da TuxCare oferece patches contínuos para versões do MySQL sem suporte, cobrindo todas as dependências, para que sua infraestrutura de banco de dados permaneça protegida enquanto você realiza a atualização no seu próprio ritmo.
O que é o ciclo de vida do produto do MySQL?
O ciclo de vida do MySQL segue a Política de Suporte Vitalício da Oracle, que define três fases distintas para cada versão principal:
- Suporte Premier 5 anos a partir da data de lançamento da versão para disponibilidade geral. Durante essa fase, a Oracle fornece novos recursos, correções de bugs, alertas de segurança e atualizações de patches críticos em um ritmo trimestral regular por meio do programa Critical Patch Update (CPU) da Oracle.
- Suporte Estendido 3 anos após o Suporte Premier, mediante o pagamento de uma taxa adicional. Os alertas de segurança e as atualizações de patches críticos continuam, mas não há novos recursos nem correções gerais de bugs.
- Suporte de Manutenção Disponível após o término do Suporte Estendido, por qualquer período de tempo. É importante ressaltar que esta fase oferece nenhuma nova versão, nenhuma nova correção de bug e nenhum novo patch de segurança. Apenas as correções já existentes permanecem acessíveis.
Quando a comunidade de bancos de dados se refere a uma versão do MySQL que chega ao fim de sua vida útil, isso significa que a versão saiu completamente do Suporte Estendido ou, como no caso do MySQL 5.7, que a Oracle a transferiu para o Suporte de Manutenção, o que, na prática, significa que não haverá mais novos patches de segurança a partir desse momento.
O MySQL introduziu um modelo de lançamento de duas vertentes em 2023 para oferecer às organizações uma previsibilidade mais clara do ciclo de vida daqui para frente:
- As versões com Suporte de Longo Prazo (LTS) são projetadas para garantir a estabilidade em produção. Cada versão LTS recebe 5 anos de Suporte Premier, além de 3 anos de Suporte Estendido. O MySQL 8.4 é a versão LTS atual.
- Versões de inovação Lançamentos trimestrais que trazem os recursos mais recentes. Cada lançamento “Inovação” recebe suporte apenas até o lançamento do próximo, o que os torna inadequados para ambientes de produção que exigem janelas de aplicação de patches previsíveis.\
| Versão do MySQL | Status | Notas |
| 5.7 | Fim da vida útil (EOL): outubro de 2023 | Apenas suporte de manutenção — sem novos patches de segurança |
| 8.0 | Fim da vida útil: abril de 2026 | Fim do suporte estendido — não haverá mais atualizações após abril de 2026 |
| 8.4 LTS | Compatível | Suporte Premier para a versão LTS atual até aproximadamente 2029 |
| 9.x (Inovação) | Rolando | Cada versão é substituída pela próxima versão trimestral |
A lição prática: se sua frota estiver rodando o MySQL 5.7, você vem operando sem patches de segurança do desenvolvedor original desde outubro de 2023. Se estiver rodando o MySQL 8.0, o prazo já está correndo até a data de fim de vida útil (EOL) do MySQL, em abril de 2026.
O que significa o fim do ciclo de vida do MySQL?
Chega de patches de segurança
Quando uma versão do MySQL entra na fase de Suporte de Manutenção, a Oracle deixa de desenvolver correções de segurança para ela. Isso significa que todas as vulnerabilidades divulgadas a partir desse momento nos componentes principais do MySQL, em seu otimizador de consultas, em seu sistema de replicação e em suas bibliotecas integradas receberão um patch para as versões com suporte, mas nada para a sua.
Essa é a principal realidade em termos de segurança ao utilizar software sem suporte em grande escala: a comunidade de pesquisa de vulnerabilidades e a própria equipe de segurança da Oracle continuam identificando e divulgando problemas de forma contínua. O ciclo trimestral de Atualizações Críticas de Patches (CPU), que costumava fornecer correções para a sua versão, simplesmente deixa de se aplicar a ela. Sua exposição aumenta a cada ciclo de CPU que passa sem que sua versão esteja incluída no escopo.
Riscos de segurança e conformidade após o fim da vida útil do MySQL (EOL)
O panorama da conformidade é igualmente inequívoco. O PCI DSS (Requisito 6.3.3) exige que vulnerabilidades críticas e de alta gravidade, com pontuação CVSS igual ou superior a 7,0, sejam corrigidas no prazo de um mês a partir do lançamento da correção para os sistemas abrangidos. A HIPAA, o FedRAMP e o SOC 2 contêm requisitos comparáveis para os ambientes que regulamentam. Utilizar uma versão do MySQL sem suporte em qualquer ambiente regulamentado significa operar um banco de dados que não pode ser corrigido dentro dos prazos exigidos por essas estruturas, o que cria uma lacuna de conformidade que os controles compensatórios só conseguem resolver parcialmente.
A posição do MySQL como banco de dados para cargas de trabalho de aplicativos que armazenam registros de clientes, transações financeiras, credenciais de autenticação e dados essenciais para os negócios faz dele um alvo prioritário para qualquer invasor que identifique uma implantação sem patches em uma versão sem suporte.
Histórico de CVEs do MySQL
O registro CVE do MySQL ilustra como funciona, na prática, a exposição após o fim do ciclo de vida (EOL).
CVE-2023-21980 CVSS 7.1 Alta. Essa vulnerabilidade afetou o componente de programas clientes do MySQL Server nas versões 5.7.41 e anteriores, e 8.0.32 e anteriores. Um invasor com privilégios limitados e acesso à rede poderia explorar essa falha para obter controle total do MySQL Server, comprometendo simultaneamente a confidencialidade, a integridade e a disponibilidade. A Oracle lançou patches para as versões suportadas como parte da Atualização de Patches Críticos de abril de 2023. Qualquer implantação que executasse o MySQL 5.7 após a data de fim de vida útil (EOL) em outubro de 2023 não recebeu nenhum caminho de correção da Oracle daqui em diante; a correção existia, mas apenas para versões com suporte. Esse é o padrão característico da exposição do MySQL após o fim de vida útil: patches são lançados para versões com suporte, enquanto implantações fora de suporte acumulam CVEs não resolvidos, sem nenhuma correção disponível no código-fonte.
O que torna esse padrão particularmente significativo é o volume. Os ciclos de CPU trimestrais da Oracle abordam regularmente um número de vulnerabilidades do MySQL na casa dos dois dígitos em diversos componentes, incluindo o InnoDB, o Otimizador, a Replicação, o DDL, os programas de cliente e muito mais. Cada ciclo de CPU que se passa após o fim da vida útil (EOL) do MySQL representa um lote de correções que sua implantação nunca recebe. A exposição cumulativa cresce a cada trimestre.
O Problema da Superfície de Dependência
O MySQL não é um binário independente; trata-se de um servidor compilado que inclui um conjunto significativo de bibliotecas C de terceiros, cada uma com sua própria superfície de vulnerabilidade. Quando o MySQL é distribuído, ele vincula ou inclui bibliotecas como o OpenSSL para criptografia TLS, o curl para operações HTTP, o LZ4 para compactação, o zlib para compactação geral de dados e o libevent para gerenciamento de eventos de rede, entre outras.
Cada uma dessas bibliotecas integradas possui seu próprio histórico de CVEs e seu próprio ritmo de lançamento independente. A Atualização Trimestral de Patches Críticos (Critical Patch Update) da Oracle corrige vulnerabilidades nesses componentes integrados, atualizando a versão do OpenSSL que vem com o MySQL quando uma vulnerabilidade crítica de TLS é divulgada, ou aplicando patches ao curl integrado quando é encontrada uma falha no tratamento de rede.
Após o fim do suporte (EOL) do MySQL, nenhuma dessas atualizações de bibliotecas integradas será aplicada à sua versão. Uma vulnerabilidade crítica no OpenSSL, uma falha de corrupção de memória no curl e um estouro de buffer no LZ4: todas essas falhas receberão correções nas versões do MySQL com suporte, mas nenhuma delas na sua. A área de risco não se limita ao próprio código de processamento de consultas do MySQL; ela se estende a todas as bibliotecas que o MySQL incorporou em seu código.
Isso ficou evidente durante o período de suporte do MySQL 5.7: os alertas de patch da Tenable para as versões do MySQL 5.7 listavam consistentemente CVEs em componentes integrados, como o curl (CVE-2021-22901, uma vulnerabilidade do tipo “use-after-free” que possibilita um potencial RCE), LZ4 (CVE-2019-17543, um estouro de heap) e OpenSSL (CVE-2021-3711, um estouro de buffer que poderia resultar no controle do servidor) como vulnerabilidades corrigidas pelas versões de patch do MySQL, demonstrando exatamente o quão profundamente a exposição das bibliotecas integradas está incorporada à superfície de ataque do MySQL. Assim que o fim da vida útil (EOL) do MySQL ocorrer, todas essas vias de correção serão encerradas.
Opções para manter a segurança e a conformidade após o fim da vida útil do MySQL (EOL)
Atualize para uma versão compatível do MySQL
A migração para o MySQL 8.4 LTS é o caminho recomendado a longo prazo para qualquer organização que ainda utilize o MySQL 5.7 ou que esteja se preparando para a data de fim de vida útil do MySQL 8.0, prevista para abril de 2026. O MySQL 8.4 LTS é a versão atual da Oracle, pronta para produção e com suporte de longo prazo, que conta com o Premier Support até aproximadamente 2029.
A complexidade dessa migração depende muito do seu ambiente. Uma frota de servidores MySQL não é atualizada da mesma forma que uma única instância de desenvolvimento — ela requer implementações coordenadas com controle de mudanças, implantações em fases entre as equipes de aplicativos, validação da compatibilidade de esquemas com camadas ORM e consultas de aplicativos, reconfiguração de topologias de replicação e testes em ambientes de teste que espelham a produção. Para organizações que executam o MySQL 5.7 e estão atualizando diretamente para a versão 8.4, a diferença abrange duas versões principais, o que traz uma área adicional de compatibilidade a ser verificada.
Migrar para um banco de dados alternativo
Algumas organizações utilizam um evento de fim de vida útil (EOL) do MySQL como gatilho para avaliar alternativas, como o PostgreSQL, o MariaDB ou serviços gerenciados de banco de dados em nuvem que abstraem o gerenciamento do ciclo de vida das versões. Essas são opções genuinamente viáveis a longo prazo para alguns ambientes, mas tratam-se de projetos de engenharia que se estendem por vários trimestres, e não de respostas a um prazo para a aplicação de patches.
Para a maioria das organizações que enfrentam uma data de fim de vida útil em curto prazo, a migração de plataforma não é uma solução viável para a lacuna imediata em termos de segurança e conformidade.
Você também pode descobrir o que o fim da vida útil (EOL) do MariaDB 10.6 significa para as equipes que estão considerando essa opção em nosso guia detalhado.
O caminho recomendado: Suporte de ciclo de vida ilimitado da TuxCare para o MySQL
O Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare para o MySQL resolve diretamente o problema de segurança e conformidade decorrente do fim da vida útil (EOL) do MySQL, sem exigir uma migração imediata para uma versão principal. A TuxCare fornece patches de segurança contínuos para versões do MySQL sem suporte, abrangendo tanto os componentes próprios do MySQL quanto as dependências de bibliotecas de terceiros incluídas no pacote, sem custo adicional, permitindo que seu parque de bancos de dados mantenha uma postura de segurança defensável enquanto você planeja a atualização que realmente deseja realizar.
O funcionamento é prático: a TuxCare monitora o NVD, os alertas de segurança da Oracle e os feeds de segurança das bibliotecas de origem em busca de vulnerabilidades que afetem o MySQL e seus componentes integrados; em seguida, faz o backport e fornece correções para versões em fim de vida útil (EOL) por meio de processos respaldados por um SLA. Sua versão do MySQL continua funcionando. Sua conformidade é mantida. E o cronograma de atualização segue de acordo com suas condições.
Os riscos de apressar uma atualização do MySQL
Quando chegam as datas de fim de vida útil (EOL) do MySQL, a pressão para reagir imediatamente é real, mas o custo de uma reação inadequada é maior do que a maioria das equipes imagina.
O que uma atualização do MySQL realmente envolve
Uma atualização de versão principal do MySQL, especialmente da 5.7 para a 8.4 em um conjunto de servidores de produção, não é uma reinicialização gradual. Isso envolve adaptação de código para quaisquer consultas de aplicativos, procedimentos armazenados ou SQL gerado por ORM que dependam de sintaxe ou comportamento que tenham mudado entre as versões. Isso envolve verificação de compatibilidade de todas as bibliotecas de clientes de banco de dados, conectores e versões de ORM que sua pilha de aplicativos utiliza, já que as matrizes de suporte de versão para frameworks como Django, Rails, Hibernate e outros precisam ser confirmadas em relação à versão-alvo do MySQL. Isso envolve adaptação da cadeia de ferramentas para pipelines de backup, exportadores de monitoramento e ferramentas de migração de banco de dados que se integram diretamente aos mecanismos internos do MySQL. E envolve sobrecarga de testes planos de consulta, alterações entre versões do otimizador, mudanças no comportamento dos índices e casos extremos nas consultas da aplicação que só se manifestam sob carga em condições semelhantes às de produção.
Em uma frota corporativa composta por centenas ou milhares de servidores de banco de dados com dependências heterogêneas de aplicativos, janelas de aplicação de patches regidas por processos de controle de mudanças e dependências de serviço que exigem validação coordenada, trata-se de um programa de trabalho coordenado, e não de uma migração de fim de semana.
O que acontece quando a atualização é feita às pressas
Quando as equipes são forçadas a realizar uma atualização do MySQL devido a um prazo de conformidade, e não por estarem preparadas, o padrão que se segue é consistente. A carga de suporte dispara à medida que as equipes de aplicativos descobrem problemas de compatibilidade de consultas que não foram detectados no ambiente de teste. A instabilidade do sistema se manifesta como atraso na replicação, comportamento inesperado dos índices ou regressões no plano de consulta que afetam a latência em produção. A dívida técnica se acumula à medida que soluções provisórias são implementadas para cumprir o prazo, gerando retrabalho que precisa ser resolvido em sprints subsequentes. E os custos não planejados aumentam em termos de tempo de engenharia, possíveis interrupções no serviço e sobrecarga operacional para gerenciar uma migração cujo escopo não foi devidamente definido antes de seu início.
As organizações que lidam bem com as transições de fim de vida útil (EOL) do MySQL as tratam como migrações planejadas, com escopo definido, tempo adequado para testes e uma postura de segurança estável mantida durante todo o processo, e não como respostas de emergência a um prazo para o qual não estavam preparadas.
A solução fácil: TuxCare ELS para MySQL
A TuxCare vem dedicando mais de uma década ao aprimoramento da automação, da expertise e dos processos que lhe permitem fornecer patches de segurança para softwares em fim de vida útil de maneira confiável e em grande escala. Com mais de 220.000 patches fornecidos em todo o seu portfólio de produtos suportados, a TuxCare desenvolveu um fluxo de trabalho de aplicação de patches que é rápido e seguro para o ambiente de produção.
No caso específico do MySQL, o ELS da TuxCare preenche a lacuna de segurança criada pelo fim do suporte (EOL) do MySQL:
- Patches de segurança rápidos, com garantia de SLA. A TuxCare monitora continuamente as divulgações de vulnerabilidades e fornece patches para CVEs de alto risco e críticos (CVSS 7.0+) de acordo com SLAs definidos, mantendo suas implantações do MySQL dentro dos prazos de aplicação de patches exigidos pelas normas PCI DSS, HIPAA, FedRAMP e outras estruturas de conformidade.
- Cobertura completa da superfície de dependências: A TuxCare cobre tanto a superfície de vulnerabilidades do próprio MySQL quanto as bibliotecas de terceiros incluídas — OpenSSL, curl, LZ4 e outras — sem custo adicional. A exposição oculta ao fim de vida útil (EOL) nas dependências compiladas do MySQL não se torna um problema para você.
- Integração perfeita com seus fluxos de trabalho existentes. Quer você gerencie atualmente as atualizações do MySQL por meio de gerenciadores de pacotes, ferramentas de gerenciamento de configuração ou seus pipelines de CI/CD existentes, é possível mudar sua fonte de atualização para o repositório seguro da TuxCare com alterações mínimas em seu fluxo de trabalho atual. Não há interrupção em sua cadeia de ferramentas atual.
- Pacotes assinados e à prova de adulteração. Cada patch fornecido pela TuxCare passa por testes exaustivos de integridade, funcionalidade e regressão antes de chegar ao seu repositório, e os pacotes são assinados criptograficamente para que você saiba exatamente o que está implantando.
- Suporte especializado 24 horas por dia, 7 dias por semana A equipe de segurança da TuxCare está disponível 24 horas por dia, 7 dias por semana, para triagem de vulnerabilidades, solicitações de patches e solução de problemas, para que você nunca precise lidar com um incidente de segurança relacionado ao fim da vida útil (EOL) do MySQL sem o suporte de especialistas.
Para verificar quais CVEs do MySQL já foram corrigidos, a TuxCare mantém um rastreador de CVEs em tempo real. Para obter mais detalhes sobre o processo de aplicação de patches e os padrões de validação da TuxCare, consulte o documento técnico.
Não deixe que o fim da vida útil do MySQL coloque sua infraestrutura de banco de dados em risco
O fim da vida útil (EOL) do MySQL não significa que seus bancos de dados fiquem imediatamente comprometidos. Mas significa que a proteção de segurança da qual sua infraestrutura dependia deixou de existir, e cada CVE publicado a partir desse momento representa um risco que você está correndo sem uma solução de correção vinda do desenvolvedor original.
As equipes que lidam bem com isso são aquelas que tratam o fim da vida útil (EOL) do MySQL como um problema de segurança a ser gerenciado de forma planejada, e não como um prazo ao qual se deve reagir sob pressão. É possível planejar uma migração bem planejada para o MySQL 8.4 LTS quando ela realmente se adequar à capacidade da sua infraestrutura, ao grau de preparação das equipes de desenvolvimento e aos processos de gestão de mudanças da sua organização. Você pode definir o escopo da migração adequadamente antes de se comprometer com um cronograma. Ou pode usar o TuxCare ELS para manter a segurança e a conformidade enquanto toma essas decisões nos seus próprios termos, e não sob a pressão do cronograma de uma auditoria de conformidade.
O ELS para MySQL não é uma solução provisória. É a opção que mantém seu parque de bancos de dados seguro, sua conformidade intacta e suas equipes de engenharia focadas no desenvolvimento, e não no gerenciamento de migrações de emergência.
Se o fim do suporte (EOL) do MySQL está no seu radar de segurança no momento, acesse Suporte de Ciclo de Vida Ilimitado da TuxCare para Software de Código Aberto para ver como o suporte estendido pode proteger sua infraestrutura de banco de dados pelo tempo que você precisar.
