Alta Disponibilidade MySQL¶

Um banco MySQL sozinho é um ponto único de falha: um disco, um kernel panic ou uma manutenção não planejada derrubam a aplicação inteira. Alta disponibilidade (HA) significa manter mais de uma cópia do banco pronta para assumir, com promoção automática e sem intervenção manual no meio da madrugada.

Esta página trata de HA dentro do mesmo datacenter — a topologia mais comum e a que resolve a maior parte das falhas reais (hardware, host, rack, manutenção). Para distribuição entre regiões e redução de latência entre países, veja MySQL Multi-Região.

A InteSys implanta essa arquitetura das duas formas: em Kubernetes, com um operador cuidando do ciclo de vida do banco, ou em máquinas virtuais, com replicação clássica e um gerenciador de cluster. As duas rodam em br-sp-1 (Cirion SAO1) e br-sp-2 (Equinix SP3).

O que HA resolve — e o que não resolve¶

Os dois números que definem o projeto:

• RPO (Recovery Point Objective) — quanto de dado é aceitável perder. Replicação assíncrona: segundos. Semi-síncrona: praticamente zero.
• RTO (Recovery Time Objective) — quanto tempo até voltar. Failover automatizado: dezenas de segundos. Manual: o tempo de alguém acordar.

Topologia em Kubernetes¶

Para clientes que já rodam suas aplicações em Kubernetes, o MySQL fica no próprio cluster, gerenciado por um operador MySQL que trata provisionamento, replicação, failover e backup como estado declarativo.

O operador reconcilia a topologia desejada; a aplicação usa um único service, e o backup sai do cluster para armazenamento de objetos.

• Topologia declarativa — número de réplicas, versão do MySQL e política de backup em manifesto, versionados em Git junto com a aplicação.
• StatefulSet com volumes persistentes — cada instância tem seu volume, com snapshot de volume criptografado e retenção definida.
• Anti-affinity obrigatória — um pod de banco por nó físico. Três réplicas no mesmo hipervisor não são alta disponibilidade.
• Endpoint único com read/write split — escritas no primário, leituras distribuídas entre as réplicas.
• Failover conduzido pelo operador — detecção, promoção e reconfiguração dos demais nós sem intervenção.
• Backup e PITR fora do cluster, em armazenamento de objetos.

Topologia em máquinas virtuais¶

Quando a aplicação não é containerizada — ou quando o banco precisa ficar fora do cluster por decisão de risco — a mesma garantia é entregue com VMs dedicadas.

Um par de ProxySQL responde por um VIP e esconde a topologia da aplicação; o gerenciador de cluster observa a saúde dos nós e conduz a promoção.

• Três nós de banco — um primário e duas réplicas, em hosts físicos distintos.
• Replicação com GTID — reposicionamento automático da réplica após a troca de primário, sem cálculo manual de coordenadas do binlog.
• Camada de proxy em par — ProxySQL com VIP/keepalived, para que a aplicação nunca precise saber qual nó é o primário.
• Gerenciador de cluster — health check, quórum de decisão, promoção e fencing do nó antigo.
• Backup e binlog fora dos nós de banco.

Kubernetes ou máquinas virtuais?¶

Não há resposta única: a InteSys opera as duas topologias e a escolha costuma seguir onde a aplicação já vive.

Como funciona o failover¶

1. Detecção — perda de contato com o primário confirmada por mais de um observador, para não reagir a uma falha de rede momentânea.
2. Fencing — o primário antigo é isolado antes de qualquer promoção. Sem isso, dois nós aceitam escrita e o split-brain corrompe os dados.
3. Promoção — a réplica mais avançada assume, após verificação de replication lag.
4. Redirecionamento — o proxy passa a apontar para o novo primário; a aplicação continua usando o mesmo endereço.
5. Reconstrução — o nó antigo volta ao cluster como réplica, automaticamente ou após inspeção, conforme a política acordada.

Modos de replicação¶

A combinação usual: uma réplica semi-síncrona para garantir o dado e uma réplica assíncrona para atender leitura e backup sem impactar o tempo de resposta das escritas.

Monitoramento que acompanha o cluster¶

Alta disponibilidade sem observabilidade é aposta. Todo cluster entregue inclui:

• replication lag por réplica, com alerta antes de o atraso virar problema;
• estado do gerenciador de cluster e histórico de promoções;
• saturação de conexões e fila no proxy;
• taxa de erro e latência de commit;
• sucesso do backup e da restauração de teste — backup que nunca foi restaurado é hipótese, não garantia.

Soberania de dados¶

Todo o dado deste cluster fica no Brasil. As duas regiões da InteSys são brasileiras — br-sp-1 (Cirion SAO1), em Cotia/SP, e br-sp-2 (Equinix SP3), na região metropolitana de São Paulo — e o dado só sai do país se o cliente pedir.

• Residência de dados no Brasil — nós primários, réplicas, arquivos de log de transação e backups ficam em datacenter brasileiro, em infraestrutura operada pela InteSys.
• LGPD sem transferência internacional — na configuração padrão não existe transferência internacional de dados pessoais para documentar, nem base legal adicional a construir.
• Jurisdição única — infraestrutura brasileira, contrato brasileiro e operação por equipe brasileira, sem a exposição a legislação estrangeira de acesso a dados que alcança provedores sediados fora do país.
• Latência como consequência — manter o dado perto do usuário brasileiro é, ao mesmo tempo, requisito de conformidade e ganho de desempenho.
• Saída de dados é decisão explícita do cliente — qualquer cópia fora do país existe apenas quando pedida, e apenas em volume criptografado.

Snapshot de volume criptografado¶

Além do backup completo com binlog para point-in-time recovery, o cluster em Kubernetes pode usar snapshots de volume (VolumeSnapshot via CSI): uma cópia do volume inteiro, tirada em segundos, sem varrer a base.

• Snapshot consistente — o operador coordena o flush e o congelamento da escrita antes de disparar o snapshot, para que a restauração não dependa de recuperação de falha.
• Sempre em volume criptografado — o dado é cifrado em repouso e o snapshot herda essa criptografia; a chave é gerenciada pela InteSys ou fornecida pelo cliente.
• Cópia cifrada em trânsito — a replicação do snapshot para outro destino trafega criptografada e é armazenada cifrada no destino.
• Retenção e restauração testada — política de retenção definida e restauração exercitada periodicamente; snapshot que nunca foi restaurado é hipótese, não backup.
• Recuperação rápida — o snapshot devolve o volume inteiro em minutos; o backup completo mais binlog continua sendo o que permite voltar ao instante anterior ao DROP TABLE.

Como a InteSys implanta¶

1. Dimensionamento — volume de dados, perfil de escrita, requisitos de RPO/RTO e janela de manutenção.
2. Topologia — decisão entre Kubernetes e VMs, número de réplicas e modo de replicação.
3. Provisionamento — nós distribuídos entre hosts físicos distintos, com anti-affinity e storage dedicado.
4. Camada de acesso — ProxySQL ou service com read/write split, endpoint único para a aplicação.
5. Backup e PITR — backup completo mais binlog em armazenamento de objetos, fora dos nós de banco.
6. Teste de falha — derrubamos o primário em ambiente controlado e medimos RTO real antes de entrar em produção.
7. Observabilidade e alertas — métricas, painéis e alertas ligados ao time de operação.
8. Runbook — procedimento documentado para os casos em que a automação precisa de decisão humana.

Próximos Passos¶

• Alta Disponibilidade PostgreSQL — A mesma arquitetura aplicada ao PostgreSQL
• Alta Disponibilidade ClickHouse — Réplicas e shards para cargas analíticas
• MySQL Multi-Região — Latência, réplicas de leitura e distribuição geográfica
• Kubernetes — Clusters gerenciados onde o banco pode ser operado
• Datacenters InteSys — Detalhes das regiões br-sp-1 e br-sp-2