Alta disponibilidad de MySQL en 2026 — ¿Galera, InnoDB Cluster o réplicas async?

La alta disponibilidad de MySQL se divide en tres opciones reales en 2026: replicación async con failover manual u orquestado, multi-primary basado en Galera (Percona XtraDB Cluster / MariaDB Galera), o MySQL Group Replication vía InnoDB Cluster. Cada uno hace un trade-off distinto entre latencia de commit, conflictos de escritura y complejidad operativa.

La respuesta equivocada es «vamos a montar CHANGE MASTER TO y esperar». Lo vemos en todas partes. No sobrevive a una caída del primary con una historia de integridad de datos defendible.

Un bootstrap funcional de InnoDB Cluster

-- en cada nodo
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';
 
-- en un nodo
SET PERSIST group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET PERSIST group_replication_bootstrap_group=OFF;

MySQL Router delante, configurado para seguir al primary. Failover por debajo de 15 segundos.

El artículo completo cubre:

• Replicación async: cuándo es realmente suficiente, y los orquestadores (Orchestrator, MHA) que la hacen sobrevivir a un fallo
• Trade-offs de Galera: certificación síncrona, el impuesto de los conflictos de escritura, y el dimensionado del gcache que nadie planifica
• InnoDB Cluster: más simple que Galera, pero con sus propias rarezas de failover
• El árbol de decisión que ejecutamos con clientes (ratio lectura/escritura, concurrencia de escritura, dispersión geográfica)
• Interacción con backups: XtraBackup en nodos Galera vs InnoDB Cluster
• Pegas del lado aplicación (offsets de auto-increment, consistencia read-after-write)

Desplegamos esto para cada cliente MySQL gestionado que necesita HA.