Como o Uber atualizou sua infraestrutura MySQL da versão 5.7 para 8.0 · rafael

O Uber atualizou sua infraestrutura MySQL da versão 5.7, lançada em 2015, para a 8.0, de 2018. Mas por que essa atualização foi necessária? E por que não optar pela versão LTS mais recente, o MySQL 8.4, lançado em 2024? Alguns engenheiros do Uber compartilharam esse processo no blog da empresa, e eu resumi os principais pontos. Você vai ver como eles planejaram essa transição, a estratégia adotada e, o mais importante, se a mudança realmente valeu a pena.

Por que atualizar?

No ano de 2023, o Uber decidiu atualizar sua infraestrutura MySQL. Um dos principais motivos era o fim do suporte estendido para a versão 5.7, que aconteceria em outubro de 2023. Além disso, a equipe do Uber levantou outros benefícios que teriam ao atualizar a versão:

Melhor desempenho e concorrência no MySQL 8.0.
Novas funcionalidades como suporte para funções de janela (window functions), tratamento JSON aprimorado e melhores recursos de dados espaciais.
Rotação de senhas: dual passwords.
Tempo de inatividade reduzido durante alterações de esquema com INSTANT ADD.

Além disso, como a nova versão LTS do MySQL foi lançada apenas em 2024 (vide tabela abaixo), realizar uma mudança de rota para utilizar a versão mais recente teria um risco maior.

Versão	Data de lançamento	Fim do suporte estendido
8.4 (LTS)	10/04/2024	30/04/2032
8.0 (LTS)	08/04/2018	30/04/2026
5.7	09/10/2015	31/10/2023

Fonte.

A infraestrutura

Terminando o ano de 2023 com 150 milhões de usuários ativos e com mais de 9.4 bilhões de viagens realizadas pelo app, a infraestrutura MySQL do Uber contava com:

2.100 clusters, distribuídos em 19 zonas, com mais de 16.000 nós.
Múltiplos petabytes de dados, com 3 milhões de consultas por segundo.
Arquitetura em cluster para redundância.
Replicação Primária-Secundária: em cada cluster, um nó primário gerencia todo o tráfego de escrita, enquanto nós secundários replicam dados de forma assíncrona.

Essa forma de replicação traz uma consideração extra sobre o planejamento da atualização: embora a replicação primária do MySQL 5.7 para a réplica de leitura do MySQL 8.0 seja compatível, o cenário inverso não é suportado.

Estratégia de atualização

A estratégia escolhida para atualizar o MySQL foi manter ambas versões executando lado a lado. Isso possibilita:

Tempo de inatividade mínimo.
Risco reduzido, com a possibilidade de reverter para os nós MySQL 5.7 caso ocorra algum problema nos nós MySQL 8.0.
Testar os novos nós com carga de aplicativo somente leitura em produção, antes de efetivar a troca dos nós antigos pelos novos.

Atualização dos clusters lado a lado

Após o planejamento, o Uber desenvolveu um sistema para automatizar a transição de um cluster MySQL 5.7 para 8.0, com alertas e monitoramento.

Passo a passo da atualização

Para conseguir atualizar conforme a estratégia definida, os passos são os seguintes:

Replicação de nós: para cada nó MySQL 5.7 no cluster, um nó de réplica MySQL 8.0 correspondente é adicionado na mesma região/zona.
Período de imersão: período de monitoramento de uma semana para observar o desempenho do sistema e detectar degradações ou violações de SLA causadas pelos nós de versão mais recente.

Criação das réplicas no MySQL 8.0

Desvio de tráfego: os nós de réplica do MySQL 5.7 são desabilitados para desviar o tráfego deles.
Promoção de nó primário: um nó MySQL 8.0 é promovido ao status primário do cluster. Tentar reverter essa promoção pode acarretar em perda de dados, pois quaisquer alterações feitas no nó MySQL 8.0 primário não seriam replicadas de volta para o MySQL 5.7 por questões de compatibilidade.

Desabilitando nós do MySQL 5.7

Remoção de nós antigos: todos os nós MySQL 5.7 são removidos.

Remoção dos nós MySQL 5.7

Problemas na atualização

Durante o processo de atualização, ocorreram alguns problemas:

Mudança de plano de execução das consultas: alguns clusters tiveram um aumento de latência e consumo de recursos. Para resolver esse problema, o Uber colaborou com a Percona, identificaram uma correção de patch e a implementaram nos clusters afetados.
Consultas e configurações não suportadas: alterações de sintaxe de certas palavras-chave interromperam algumas consultas. Além disso, uma parte dos clusters não tinha o modo STRICT_TRANS_TABLES habilitado, que é uma configuração padrão no MySQL 8.0. Isso resultou em erros durante o procedimento de atualização. Também ocorreram erros com o modo ONLY_FULL_GROUP_BY.
Mudança no collation padrão: no MySQL 8.0, o conjunto de caracteres padrão é utf8mb4, acompanhado pelo collation utf8mb4_0900_ai_ci. O MySQL 5.7 usava utf8mb4_unicode_520_ci, sem suporte para o mais recente utf8mb4_0900_ai_ci.
Incompatibilidade da biblioteca do cliente: Muitas bibliotecas de cliente existentes eram incompatíveis com o MySQL 8.0, então precisaram atualizá-las também.

Resultados

Mesmo com as dificuldades enfrentadas, ao trabalhar com a Percona, o Uber garantiu que não estaria atualizando para algo pior. As melhorias foram significativas, o que possibilitou o Uber otimizar sua infraestrutura e abre a possibilidade de manter uma operação mais escalável com o mesmo poder computacional, ou reduzir a infraestrutura para uma operação mais econômica.

Os resultados apresentados no artigo original são:

Melhoria de 29% na latência do p99 para 1 milhão de inserções em 1024 threads.
Melhoria de 33% na latência do p99 para 1 milhão de leituras em 1024 threads.
Melhoria de 47% na latência do p99 para 1 milhão de atualizações em 1024 threads. (talvez este percentual esteja errado, porque no gráfico não aparenta ser 47%)
~94% de redução no tempo geral de bloqueio (lock) do banco de dados.
~78% de redução no tempo de consulta para algumas consultas.