OpenEverest expõe failover automático de cluster MySQL Galera sem perda de dados

O que a Percona testou, e por que importa

No dia 12 de novembro de 2026, a Percona publicou a segunda parte de uma série sobre o OpenEverest, seu operador Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps → para bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →. O autor, Arunjith Aravindan, já havia montado na Parte 1 um cluster K3s de três nós e criado sobre ele um Percona XtraDB Cluster (PXC) de três réplicas chamado mysql-vjg. Nesta segunda parte, o teste é mais interessante para quem programa contra o banco do que para quem só administra: ele mata o pod escritor enquanto um cliente insere uma linha por segundo, e observa o que a aplicação enxerga durante a troca.

Para quem constrói sistemas que dependem de MySQL em Kubernetes, essa é a pergunta que todo mundo evita até o incidente acontecer em produção: quando o pod que recebe escrita morre, o cliente vê erro, vê lentidão, ou nem percebe? O artigo da Percona responde com números reais de um cluster de laboratório, não com promessa de marketing.

Como ler a saúde de um cluster Galera

O PXC replica dados usando a biblioteca Galera, que expõe seu estado através de variáveis wsrep_* (de write-set replication). Um write-set é o pacote de mudanças de linha gerado por uma transação; no commit, ele é enviado a todos os nós e passa por certificação antes de ser confirmado. Rodar SHOW STATUS LIKE '%wsrep%stat%' é o equivalente, em Galera, a checar o SHOW SLAVE STATUS da replicação tradicional.

Um detalhe que todo dev que já apanhou de "deadlock" em Galera deveria conhecer: wsrep_local_cert_failures conta transações que falharam na certificação porque outro nó mudou as mesmas linhas primeiro. É o Galera recusando uma escrita concorrente, não um bug de aplicação. wsrep_local_bf_aborts, por sua vez, mostra transações locais abortadas à força por um write-set replicado (o chamado brute-force abort): em cargas de escrita pesada e concorrente, esses dois contadores sobem juntos e indicam que o padrão de acesso à tabela precisa mudar, não que o cluster está quebrado.

A máquina de estados de um nó que entra ou sai

Todo nó que se junta ao cluster passa por uma sequência fixa de estados, visível em wsrep_local_state:

1. Joining: o nó entrou no grupo e está pedindo os dados que lhe faltam.
2. Donor/Desynced: o nó está enviando uma transferência de estado para outro que está entrando; o HAProxy o tira de rotação enquanto isso ocorre.
3. Joined: o nó recebeu os dados e aplica os write-sets acumulados na fila.
4. Synced: o nó está em dia; só nós neste estado recebem tráfego do HAProxy.

A forma como o nó recupera o que perdeu é o ponto que mais afeta operação em produção. Se o gcache (o buffer circular de write-sets recentes) de um nó doador ainda contém tudo o que o nó que retorna perdeu, a recuperação é um IST (Incremental State Transfer): poucos segundos, pouca carga extra. Se não contém, o Galera recorre a um SST (State Snapshot Transfer): uma cópia completa do banco via Percona XtraBackup, que pode levar muito tempo e sobrecarrega o nó doador. Dimensionar o gcache corretamente é, na prática, a diferença entre um pod que sai e volta em segundos ou um que trava o cluster por minutos.

O teste: matar o escritor com tráfego real passando

A Percona montou o teste em três terminais simultâneos. Um cliente MySQL roda dentro do próprio cluster, não via túnel SSH, exatamente para que uma queda de conexão externa não seja confundida com o failover em si:

while true; do
  out=$(mysql -h mysql-vjg-haproxy -uroot --connect-timeout=2 -Nse "
    INSERT INTO demo.failover_test (served_by) VALUES (@@hostname);
    SELECT @@hostname, LAST_INSERT_ID();" 2>&1 | tr '\n\t' '  ')
  echo "$(date +%T)  $out"
  sleep 1
done

Antes do failover, toda linha impressa mostra mysql-vjg-pxc-0, o escritor atual, inserindo uma linha por segundo sem falhas. É o baseline: o artigo não começa já no caos, começa provando que o fluxo normal funciona.

Com o loop de escrita rodando, o comando que dispara o teste é de uma simplicidade quase brutal:

kubectl delete pod mysql-vjg-pxc-0 -n everest

Isso envia um SIGTERM ao pod, simulando uma manutenção planejada ou reinício de nó. O StatefulSet que o gerencia recria imediatamente um pod com o mesmo nome, mas ele entra como um nó novo: vai passar por Joining, pegar um IST (ou um SST, se o gcache for pequeno demais) e só voltar a receber tráfego ao chegar em Synced.

O que a aplicação enxerga durante a troca

A promessa que o artigo faz logo na abertura é a que mais importa para quem escreve código contra esse banco: o HAProxy troca o escritor, o pod derrubado reingressa, e os três nós terminam com dados idênticos. A checagem usada para provar isso é a mesma vista na Seção A, rodada após o teste: comparar wsrep_last_committed nos três pods via kubectl exec e confirmar que o número bate nos três.

Isso não significa zero impacto. Durante a janela entre a morte do pod escritor e o HAProxy redirecionar as conexões, o loop de escrita do teste registra timeouts ou erros de conexão (o --connect-timeout=2 existe justamente para não deixar essas tentativas penduradas). O que o teste prova não é ausência de erro transitório: é que nenhuma escrita confirmada se perde, e que o cluster volta a aceitar escritas sozinho, sem intervenção manual no banco.

Onde isso ajuda, e onde não resolve sozinho

Para quem decide se um cluster Galera orquestrado por Kubernetes vale a complexidade, valem três ressalvas que o próprio comportamento do Galera impõe:

• Quórum exige maioria: um cluster de três nós tolera a perda de um; perder dois de uma vez tira o restante do estado Primary e ele para de aceitar escritas até o quórum voltar. Isso é proteção contra split-brain, não um bug, mas significa planejar número ímpar de nós e distribuição entre zonas de disponibilidade.
• Flow control não é grátis: se um nó fica para trás na fila de aplicação (wsrep_local_recv_queue_avg subindo), o Galera pausa escritas em todo o cluster até ele se recuperar. Cargas de escrita muito pesadas em hardware desigual sofrem mais com isso do que com o failover em si.
• O operador automatiza provisionamento, não diagnóstico: o OpenEverest cuida de subir o StatefulSet, o HAProxy e os segredos do Kubernetes, mas entender se um incidente é certificação falhando, SST demorado ou flow control continua exigindo ler as variáveis wsrep_* à mão, como a Parte 2 do artigo ensina a fazer.

Para equipes que já têm esse conhecimento operacional, o ganho real do OpenEverest é reduzir o trabalho manual de orquestrar o PXC sobre Kubernetes, não eliminar a necessidade de entender Galera por baixo. Quem procura um banco gerenciado sem nenhuma curva de aprendizado em replicação síncrona provavelmente está mais bem servido por um serviço totalmente gerenciado; quem precisa de controle fino sobre failover e topologia encontra, nesse material da Percona, um roteiro reproduzível de como validar essa resiliência antes de confiar nela em produção.

Fonte: Percona Database Blog