MYSQL · ALTA DISPONIBILIDADE

    Alta Disponibilidade MySQL com InnoDB Cluster.

    HTI Tecnologia · Equipe TécnicaAtualizado em junho de 202613 min de leitura

    Por quase duas décadas, "alta disponibilidade no MySQL" significou replicação master-slave com failover manual ou MHA/Orchestrator por cima. Funcionava — e ainda funciona — mas exige cerimônia operacional e tolerância a 5-15 minutos de janela em qualquer troca de papel.

    InnoDB Cluster muda o jogo. É a stack oficial da Oracle para HA em MySQL — Group Replication + MySQL Router + MySQL Shell — com failover automático em segundos e consistência sincrônica de escrita. Este artigo é o guia técnico que usamos quando desenhamos clusters MySQL em produção, complemento direto da nossa consultoria MySQL.

    ALTA DISPONIBILIDADE MYSQL

    Precisa desenhar um InnoDB Cluster?

    Operamos clusters MySQL com 99,9999% de disponibilidade em e-commerce de alta concorrência.

    Falar com um Expert MySQL →

    01

    HA EM MYSQL: PANORAMA 2026

    Em 2026, três famílias de soluções dominam HA em MySQL: replicação assíncrona clássica (com Orchestrator ou MHA), InnoDB Cluster (Group Replication) e soluções proprietárias de cloud (Aurora MySQL, Cloud SQL HA, Azure Flexible Server). Cada uma serve um perfil diferente.

    Replicação assíncrona escala leitura e replica entre regiões — mas failover não é automático nem instantâneo. Aurora resolve HA com storage compartilhado distribuído, mas trava o cliente em AWS. InnoDB Cluster é o meio-termo: portátil entre on-prem e qualquer cloud, automático, sincrônico, mantido pela Oracle.

    02

    INNODB CLUSTER: ARQUITETURA

    InnoDB Cluster é composto por três componentes que se complementam:

    Group Replication (camada de dados)

    Plugin nativo do MySQL que faz replicação sincrônica baseada em quórum. Cada commit precisa ser certificado pela maioria dos nós antes de retornar OK ao cliente. Garante que, se a primária cair, nenhum dado commitado se perde.

    MySQL Router (camada de roteamento)

    Proxy leve que mantém um mapa do estado do cluster e roteia escritas para a primária e leituras para as réplicas. Em failover, atualiza o mapa em segundos sem que a aplicação precise reconectar manualmente.

    MySQL Shell (camada de operação)

    CLI/biblioteca Python+JS que cria, monitora e opera o cluster com comandos de uma linha: dba.createCluster(), cluster.addInstance(), cluster.status(). Esconde a complexidade de configuração manual do Group Replication.

    03

    GROUP REPLICATION POR BAIXO

    Group Replication usa o protocolo Paxos (variante XCom) para certificação distribuída. Cada transação carrega seu writeset (conjunto de linhas modificadas) e é certificada contra writesets concorrentes — se houver conflito, a transação mais antiga vence e as demais recebem rollback no commit.

    -- Parâmetros essenciais para Group Replication
    plugin_load_add = 'group_replication.so'
    group_replication_group_name = '<UUID>'
    group_replication_start_on_boot = ON
    group_replication_local_address = '10.0.0.1:33061'
    group_replication_group_seeds = '10.0.0.1:33061,10.0.0.2:33061,...'
    group_replication_consistency = 'BEFORE_ON_PRIMARY_FAILOVER'

    group_replication_consistency é o parâmetro mais subestimado: EVENTUAL (default) pode ler dados antigos durante failover; BEFORE_ON_PRIMARY_FAILOVER espera o catch-up — escolha consciente entre consistência e latência.

    04

    MYSQL ROUTER E ROTEAMENTO DE CONEXÃO

    MySQL Router expõe dois endpoints lógicos: um para leitura/escrita (apontado para a primária) e um read-only (load-balanceado entre réplicas). A aplicação conecta no Router, não diretamente nos nós — é o que torna o failover transparente.

    Em produção séria, Router roda como sidecar em cada host de aplicação (não centralizado), eliminando ponto único de falha e latência de hop extra. Configuração via mysqlrouter --bootstrap que lê metadata do cluster e gera config automaticamente.

    "Cluster sem Router em sidecar é cluster com SPOF disfarçado."

    05

    OPERAÇÃO REAL: FAILOVER, SPLIT-BRAIN, MANUTENÇÃO

    Failover automático

    Quando a primária para de responder, o quórum elege a réplica mais avançada (menor lag) como nova primária em segundos. Router detecta a mudança e redireciona conexões — aplicação enxerga reset de conexão e reconecta. Driver moderno (Connector/J, Connector/Python, mysql2 do Node) reconecta sozinho.

    Split-brain

    Em particionamento de rede, o lado sem quórum entra em modo somente-leitura automaticamente (super_read_only=ON). Quando a partição cura, o nó precisa ser rejoinado manualmente — Group Replication não força rollback automático de divergência.

    Manutenção rolling

    Upgrade de versão, troca de hardware ou patch de SO: tira-se um nó por vez do cluster com cluster.removeInstance(), atualiza, e readiciona com cluster.addInstance(). Zero downtime quando bem orquestrado.

    06

    QUANDO NÃO USAR INNODB CLUSTER

    Cluster não é solução universal. Não use se:

    • Latência entre nós > 5ms — flow control vai estrangular throughput.
    • Workload > 80% write com transações longas — certificação distribuída vira gargalo.
    • Você só precisa de read scale-out — replicação assíncrona é mais barata e simples.
    • Time não opera Linux/MySQL no nível necessário — cluster mal operado é pior que single instance bem operada.

    07

    CHECKLIST DE PRODUÇÃO

    • 3 ou 5 nós em zonas de disponibilidade distintas.
    • MySQL Router em sidecar por host de aplicação.
    • group_replication_consistency definido conforme o RPO.
    • Backup com restore testado fora do cluster (PITR via mysqlbinlog + dump físico).
    • Monitoramento de performance_schema.replication_group_members e flow control.
    • Runbook de rejoin pós split-brain ensaiado.
    • Replicação assíncrona para DR cross-region — cluster local não substitui DR.
    • Cobertura por DBA Remoto 24/7 ou time interno com plantão.

    ALTA DISPONIBILIDADE MYSQL

    Precisa desenhar um InnoDB Cluster?

    Operamos clusters MySQL com 99,9999% de disponibilidade em e-commerce de alta concorrência.

    Falar com um Expert MySQL →

    08

    PERGUNTAS FREQUENTES SOBRE INNODB CLUSTER

    InnoDB Cluster substitui replicação tradicional master-slave?

    Substitui em ambientes que precisam de failover automático e consistência sincrônica de escrita. Para read replicas analíticas e replicação geográfica de longa distância, replicação assíncrona tradicional ainda é a escolha — combinada ao cluster como source.

    Quantos nós são necessários?

    Mínimo 3 para tolerar a falha de 1 nó mantendo quórum. 5 nós toleram 2 falhas simultâneas. Número par (2, 4) é desaconselhado: divide o quórum e aumenta o risco de split-brain. Para casos extremos, 7 nós distribuídos em 3 zonas de disponibilidade.

    InnoDB Cluster funciona em multi-region?

    Não com sincronia. Group Replication exige latência inter-nó tipicamente abaixo de 5ms — multi-region intra-continental às vezes funciona, transatlântico não. Para DR cross-region, combine cluster local + replicação assíncrona para outra região.

    Qual o overhead em performance vs. instância única?

    Em workload write-heavy, espere 15–30% de queda de throughput por conta da certificação distribuída e do flow control. Reads não são afetados — escalam linearmente adicionando nós. Para casos com queda excessiva, ajuste group_replication_flow_control_mode e batch size das transações.

    É possível migrar para InnoDB Cluster sem downtime?

    Sim, usando replicação assíncrona como ponte: monta-se o cluster em paralelo, sincroniza via async replication a partir da primária atual, executa-se cut-over de roteamento via MySQL Router em janela curta (segundos). Já fizemos esse padrão dezenas de vezes em produção.

    Continue lendo