MySQL Multi-Região¶

Aplicações que rodam em uma região e acessam um banco MySQL em outra podem degradar de forma severa mesmo quando o servidor de banco tem folga de CPU, memória e disco. O gargalo raramente é o MySQL: é a rede entre a aplicação e o banco.

Cada operação SQL exige pelo menos uma ida e volta (round trip) pela WAN. Uma transação com cinco comandos paga cinco vezes a latência do enlace — e qualquer perda de pacote adiciona retransmissões TCP, picos de tempo de resposta e, no limite, timeouts na aplicação.

A InteSys atua em todas as camadas desse problema, desde otimizações transparentes para sistemas legados até arquiteturas regionais completas com replicação, cache e distribuição geográfica dos dados — operando nas duas regiões brasileiras Tier III: br-sp-1 (Cirion SAO1, Cotia/SP) e br-sp-2 (Equinix SP3, Tamboré/SP).

O problema¶

Em uma aplicação tradicional, uma única transação executa uma sequência como:

BEGIN → SELECT → UPDATE → INSERT → COMMIT

Com o banco em outra região, o tempo da transação passa a ser ditado pela rede: cinco comandos, cinco RTTs, mais as retransmissões causadas por perda de pacotes.

Entre br-sp-1 e br-sp-2 a latência é de poucos milissegundos — as duas regiões ficam na região metropolitana de São Paulo e se interligam por links Lan2Lan ou túneis criptografados. Já um enlace Brasil ↔ Estados Unidos opera em outra ordem de grandeza, acima de uma centena de milissegundos de RTT. É essa diferença que define quais consultas podem cruzar a WAN e quais precisam ser respondidas localmente.

Os objetivos de uma arquitetura regional são:

• reduzir a quantidade de acessos SQL que cruzam a WAN;
• aproximar leituras e dados de alta frequência da aplicação;
• manter as escritas consistentes e controladas;
• aumentar a tolerância à instabilidade de rede;
• preservar a compatibilidade com aplicações legadas sempre que possível;
• permitir evolução gradual, sem exigir reescrita do sistema.

Catálogo de arquiteturas¶

1. Conectividade resiliente entre regiões¶

Antes de mexer no banco, estabilizamos o transporte: caminhos redundantes, VPNs, roteamento alternativo e observabilidade contínua de RTT, jitter e perda de pacotes.

Indicado para: ambientes com perda de pacotes, rotas instáveis ou dependência de um único caminho WAN. Benefício: estabilidade e previsibilidade. Limitação: não elimina a latência física entre as regiões.

2. ProxySQL próximo da aplicação¶

O ProxySQL é instalado na mesma região da aplicação, entre ela e o MySQL remoto. Ele centraliza conexões, mantém pools persistentes e permite aplicar regras de roteamento e cache de consultas.

Indicado para: aplicações legadas, alto volume de conexões ou necessidade de uma camada de controle sem alterar o código. Benefícios: pooling de conexões, controle centralizado de queries, observabilidade por query digest, base para evoluir para réplicas locais e possibilidade de cache seletivo. Limitação: consultas não cacheadas continuam acessando a região remota.

3. Réplica de leitura no Brasil¶

O primário permanece onde está e uma réplica assíncrona é mantida em br-sp-1 ou br-sp-2. O ProxySQL encaminha as leituras adequadas para a réplica local e mantém as escritas no primário.

Indicado para: aplicações com volume relevante de leitura e tolerância a consistência eventual em parte das consultas. Benefícios: SELECT locais com baixa latência, menor uso da WAN e redução significativa do tempo médio de resposta — sem tornar a réplica gravável. Ponto de atenção: leituras imediatamente após uma escrita podem precisar ir ao primário para garantir consistência.

4. Roteamento seletivo por query¶

Em vez de mandar todo SELECT para a réplica, mapeamos quais consultas toleram consistência eventual e criamos regras específicas no ProxySQL, por digest, tabela ou usuário.

Catálogos, relatórios e dados de referência vão para a réplica local; saldo, checkout, SELECT ... FOR UPDATE e leitura logo após escrita permanecem no primário.

Benefício: adoção segura e progressiva, consulta a consulta, sem apostar tudo de uma vez.

5. Cache regional com Valkey/Redis¶

Dados repetitivos ficam em um Valkey ou Redis na região da aplicação, reduzindo drasticamente o número de consultas ao banco remoto. Bons candidatos: configurações, perfis, permissões, catálogos, sessões, resultados de consultas caras e dados derivados.

Indicado para: dados com alta taxa de leitura e estratégia de invalidação bem definida. Benefício: as consultas mais frequentes passam a ser respondidas localmente, independentemente da distância até o MySQL.

6. Arquitetura combinada — ProxySQL + réplica + cache¶

É a arquitetura com melhor relação entre ganho, risco e complexidade para sistemas já em produção, e a recomendação padrão da InteSys.

A aplicação fala com um endpoint local. O ProxySQL decide o destino de cada consulta; o cache atende os dados de alta frequência; a réplica atende as leituras selecionadas; o primário continua sendo a única autoridade de escrita.

Indicado para: sistemas críticos que precisam evoluir sem reescrita profunda.

7. Replicação parcial¶

Nem todo o banco precisa ser trazido para o Brasil. É possível replicar apenas os databases ou conjuntos de dados que a aplicação brasileira realmente consome.

Indicado para: bancos muito grandes, domínios bem separados ou cenários em que só uma fração dos dados precisa estar próxima da aplicação. Benefícios: menor volume de replicação, menor custo de infraestrutura e segmentação por domínio funcional.

8. Camada regional de API / serviço de dados¶

Em sistemas novos ou em modernização, a aplicação deixa de executar dezenas de comandos SQL pela WAN e passa a chamar uma API regional. Esse serviço executa a transação junto do banco primário ou combina cache e réplica local.

Indicado para: modernização, microsserviços e fluxos transacionais com muitos round trips. Benefício: troca vários round trips SQL por uma única chamada de negócio.

9. Sharding geográfico / ownership regional¶

Para sistemas que precisam escrever localmente em mais de uma região, os dados são particionados por cliente, tenant, país ou domínio funcional: tenants brasileiros gravam no Brasil, tenants americanos gravam nos EUA, e cada região replica o que a outra precisa apenas para leitura.

Indicado para: plataformas globais e SaaS multi-tenant. Complexidade: alta — exige regras claras de ownership, consistência e roteamento.

Alta disponibilidade entre br-sp-1 e br-sp-2¶

Reduzir latência resolve desempenho, não disponibilidade. Quando o banco é crítico, a InteSys distribui a solução entre as duas regiões brasileiras, que são independentes em energia, refrigeração e operadora, e ficam a poucos milissegundos uma da outra.

Primário em uma região, standby na outra, ProxySQL em alta disponibilidade nas duas e promoção controlada em caso de falha.

Como isso funciona na prática:

• Primário em br-sp-1, standby em br-sp-2 (ou o inverso) — a proximidade permite replicação semi-síncrona, com janela de perda de dados próxima de zero, algo inviável em enlaces intercontinentais.
• ProxySQL em alta disponibilidade nas duas regiões, com VIP/keepalived e o mesmo conjunto de regras, para que a aplicação continue usando um único endpoint.
• Failover controlado: promoção da réplica com verificação de replication lag e fencing do primário antigo, evitando split-brain.
• Backups e PITR em armazenamento separado das duas regiões, com testes periódicos de restauração.
• Leituras aproveitam o standby: a região secundária não fica ociosa — atende consultas de leitura enquanto acompanha o primário.

MySQL gerenciado em Kubernetes¶

Para clientes que já rodam suas aplicações em Kubernetes, a InteSys também opera o MySQL dentro do cluster, com um operador MySQL cuidando do ciclo de vida do banco.

O operador reconcilia o estado desejado do cluster de banco; a aplicação acessa um único service, e o backup sai do cluster para armazenamento de objetos.

O que essa abordagem entrega:

• Topologia declarativa — número de réplicas, versão do MySQL e política de backup descritos como manifesto, versionados em Git junto com a aplicação.
• StatefulSet com armazenamento persistente — cada instância tem seu volume, com snapshots e política de retenção.
• Failover automatizado pelo operador — promoção de réplica e reconfiguração da topologia sem intervenção manual.
• Endpoint único com read/write split — escritas vão para o primário, leituras se distribuem entre as réplicas, do mesmo jeito que o ProxySQL faz fora do cluster.
• Distribuição entre br-sp-1 e br-sp-2 — regras de anti-affinity espalham os pods entre as regiões, de modo que a perda de uma região não derruba o quórum.
• Backup e PITR fora do cluster, em armazenamento de objetos, porque backup dentro do mesmo cluster não é backup.

Matriz de decisão¶

Por cenário¶

O que não deve ir para a réplica¶

A regionalização de leitura só é segura se as consultas sensíveis à consistência permanecerem no primário:

Monitorar o replication lag é parte da solução, não um extra: as regras de roteamento devem reagir ao atraso, tirando a réplica de operação quando ela fica para trás.

Como a InteSys implanta¶

1. Diagnóstico — medição de RTT, jitter, perda de pacotes, volume de conexões e comportamento transacional.
2. Observabilidade — identificação das queries mais frequentes, mais lentas e mais sensíveis à WAN, por digest.
3. ProxySQL — introdução da camada de acesso centralizada e mensurável.
4. Regionalização da leitura — réplica MySQL brasileira, quando aplicável.
5. Cache — seleção dos dados adequados para Valkey/Redis e definição da estratégia de invalidação.
6. Regras de consistência — leituras críticas no primário, consultas seguras na região local.
7. Alta disponibilidade — eliminação de pontos únicos de falha em ProxySQL, cache e banco, com distribuição entre br-sp-1 e br-sp-2.
8. Evolução arquitetural — API regional, replicação parcial, Kubernetes ou sharding geográfico, conforme a necessidade.

Cada etapa é medida antes de avançar para a próxima, o que permite parar no ponto em que o ganho já atende ao objetivo.

Próximos Passos¶

• Kubernetes — Clusters gerenciados onde o MySQL pode ser operado
• Datacenters InteSys — Detalhes das regiões br-sp-1 e br-sp-2
• Visão Geral de DevOps — Catálogo completo de serviços