Alta disponibilidade de MySQL em 2026 — Galera, InnoDB Cluster ou réplicas async?

A alta disponibilidade do MySQL se divide em três opções reais em 2026: replicação async com failover manual ou orquestrado, multi-primary baseado em Galera (Percona XtraDB Cluster / MariaDB Galera), ou MySQL Group Replication via InnoDB Cluster. Cada um faz um trade-off diferente entre latência de commit, conflitos de escrita e complexidade operacional.

A resposta errada é «vamos só configurar CHANGE MASTER TO e torcer». Vemos isso em todo lugar. Não sobrevive a uma queda do primary com uma história de integridade de dados que você queira defender.

Um bootstrap funcional de InnoDB Cluster

-- em cada nó
SET PERSIST group_replication_local_address='node1:33061';
SET PERSIST group_replication_group_seeds='node1:33061,node2:33061,node3:33061';
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
 
-- em um nó
SET PERSIST group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET PERSIST group_replication_bootstrap_group=OFF;

MySQL Router na frente, configurado para seguir o primary. Failover abaixo de 15 segundos.

O artigo completo cobre:

• Replicação async: quando é de fato suficiente, e os orquestradores (Orchestrator, MHA) que a fazem sobreviver a uma falha
• Trade-offs do Galera: certificação síncrona, o imposto dos conflitos de escrita, e o dimensionamento do gcache que ninguém planeja
• InnoDB Cluster: mais simples que Galera, mas com suas próprias peculiaridades de failover
• A árvore de decisão que rodamos com clientes (razão leitura/escrita, concorrência de escrita, dispersão geográfica)
• Interação com backups: XtraBackup em nós Galera vs InnoDB Cluster
• Pegadinhas do lado da aplicação (offsets de auto-increment, consistência read-after-write)

Implantamos isso para cada cliente MySQL gerenciado que precisa de HA.