MySQL Group Replication en 2026: construcción de un clúster con failover automático sin herramientas externas

Introducción: por qué la replicación master-slave ya no es suficiente

La replicación master-slave clásica de MySQL resolvía el problema del escalado horizontal de lectura, pero nunca fue diseñada para la recuperación automática ante fallos. Cuando el maestro caía, el ingeniero tenía que promover manualmente una réplica, actualizar la cadena de conexión en la aplicación y verificar la posición del binlog, todo esto en la madrugada del viernes al sábado con las alertas sonando sin parar.

Los problemas de la replicación clásica son bien conocidos: asincronía (la réplica puede quedarse atrás), ausencia de failover automático a nivel del propio MySQL, riesgo de pérdida de transacciones al conmutar y necesidad de herramientas externas como MHA u Orchestrator para la automatización. En 2026, cuando los requisitos de SLA en la mayoría de los productos son del 99,9% o superiores, este enfoque es inaceptable para sistemas críticos.

MySQL Group Replication es un mecanismo de clustering integrado que apareció en MySQL 5.7.17 y fue significativamente mejorado en las versiones 8.0 y 8.4. Proporciona consenso síncrono a nivel de transacciones, failover automático y la capacidad de operar en varios modos sin una sola línea de código externo. Si administras MySQL en producción de forma independiente y no quieres migrar a soluciones cloud gestionadas, Group Replication es la opción más madura para construir alta disponibilidad en MySQL.

Arquitectura de MySQL Group Replication

Dos modos de operación: single-primary y multi-primary

Group Replication admite dos modos. En el modo single-primary, un nodo es el primario (primary) y acepta todas las operaciones de escritura, mientras que los demás son secundarios (secondary) y están disponibles solo para lectura. Este es el modo más seguro y recomendado: elimina los conflictos de escritura entre nodos y se corresponde con la semántica habitual de «un solo maestro».

En el modo multi-primary, todos los nodos aceptan escrituras simultáneamente. Esto aumenta el rendimiento de escritura, pero requiere un manejo cuidadoso de los conflictos: dos UPDATE simultáneos de la misma fila en nodos diferentes provocarán la reversión de una de las transacciones. Este modo es adecuado para escenarios específicos con sharding por nodos o con conflictos muy poco frecuentes.

Consenso Paxos y quórum

Internamente, Group Replication utiliza un algoritmo de consenso adaptado basado en Paxos (concretamente, la implementación XCom). Antes de que una transacción se confirme, el grupo debe alcanzar el consenso: la mayoría de los nodos (quórum) deben confirmar la recepción del evento. Para un clúster de tres nodos, el quórum son dos nodos. Esto significa:

• Si cae un nodo, el clúster sigue funcionando.
• Si caen dos de tres nodos, el clúster pierde el quórum y detiene las escrituras (protección contra el split-brain).
• El número mínimo recomendado de nodos es tres; para mayor tolerancia a fallos, cinco.

Cada transacción recibe un identificador global (GTID) y se entrega de forma atómica a todos los miembros del grupo. Solo después de la confirmación por quórum se considera que la transacción ha sido confirmada; esta es la diferencia fundamental respecto a la replicación asíncrona, donde el maestro no espera a las réplicas.

Requisitos de infraestructura

Para desplegar un clúster de Group Replication es necesario cumplir una serie de condiciones:

• Versión de MySQL: 8.0.27+ o 8.4.x (rama LTS, recomendada en 2026). MySQL 8.4 trajo mejoras en el proceso de recuperación automática de miembros y una sintaxis simplificada para varios comandos.
• Motor de almacenamiento: solo InnoDB. Las tablas en MyISAM u otros motores no son compatibles con el grupo.
• Claves primarias: cada tabla debe tener una clave primaria; sin ella, Group Replication rechazará confirmar los cambios.
• Red: baja latencia entre nodos (preferiblemente hasta 5 ms de RTT). El grupo utiliza un puerto separado para la comunicación interna (por defecto, 33061). Todos los nodos deben poder comunicarse entre sí a través de ese puerto.
• Hosts: server_id único, server_uuid único, tiempo sincronizado (NTP/chrony es obligatorio).
• GTID: debe estar habilitado en todos los nodos (gtid_mode=ON, enforce_gtid_consistency=ON).

Configuración paso a paso del clúster de tres nodos

Configuración de my.cnf

Ejemplo de configuración para el primer nodo (node1). Para node2 y node3, cambia server_id, report_host y loose-group_replication_local_address:

# /etc/mysql/mysql.conf.d/mysqld.cnf — node1

[mysqld]
# Parámetros principales
server_id = 1
bind-address = 0.0.0.0
report_host = node1.example.com

# GTID
gtid_mode = ON
enforce_gtid_consistency = ON

# Binlog
log_bin = mysql-bin
binlog_format = ROW
binlog_checksum = NONE          # obligatorio para GR
log_slave_updates = ON

# Group Replication — plugin
plugin_load_add = group_replication.so

# Nombre del grupo — UUID, igual para todos los nodos
loose-group_replication_group_name = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

# Dirección local del nodo para la comunicación interna de GR
loose-group_replication_local_address = "node1.example.com:33061"

# Lista de todos los nodos del grupo
loose-group_replication_group_seeds = \
  "node1.example.com:33061,node2.example.com:33061,node3.example.com:33061"

# No iniciar GR automáticamente al arrancar MySQL
loose-group_replication_start_on_boot = OFF

# Modo single-primary (recomendado)
loose-group_replication_single_primary_mode = ON
loose-group_replication_enforce_update_everywhere_checks = OFF

# Recuperación mediante clonación (MySQL 8.0.17+)
loose-group_replication_recovery_use_ssl = OFF

Inicialización del grupo en el primer nodo

Después de iniciar MySQL en los tres nodos, ejecuta los siguientes pasos en node1:

-- 1. Creamos el usuario para la replicación dentro del grupo
CREATE USER 'repl'@'%' IDENTIFIED BY 'StrongPassword123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
GRANT CONNECTION_ADMIN ON *.* TO 'repl'@'%';
GRANT BACKUP_ADMIN ON *.* TO 'repl'@'%';   -- necesario para la clonación
FLUSH PRIVILEGES;

-- 2. Configuramos el canal de recuperación
CHANGE MASTER TO
  MASTER_USER='repl',
  MASTER_PASSWORD='StrongPassword123!'
  FOR CHANNEL 'group_replication_recovery';

-- 3. Inicializamos el grupo (¡solo en el nodo bootstrap!)
SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;

-- 4. Verificamos el estado
SELECT * FROM performance_schema.replication_group_members;

Incorporación de node2 y node3

En cada uno de los nodos restantes, ejecuta (sin bootstrap):

-- En node2 y node3 (igual para ambos)
CREATE USER 'repl'@'%' IDENTIFIED BY 'StrongPassword123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
GRANT CONNECTION_ADMIN ON *.* TO 'repl'@'%';
GRANT BACKUP_ADMIN ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

CHANGE MASTER TO
  MASTER_USER='repl',
  MASTER_PASSWORD='StrongPassword123!'
  FOR CHANNEL 'group_replication_recovery';

-- Simplemente iniciamos — el nodo encontrará el grupo a través de seeds
START GROUP_REPLICATION;

-- Verificamos que el nodo se haya unido al grupo
SELECT MEMBER_HOST, MEMBER_STATE, MEMBER_ROLE
FROM performance_schema.replication_group_members;

Tras añadir correctamente los tres nodos, la tabla replication_group_members mostrará tres filas con el estado ONLINE: una con el rol PRIMARY y dos con el rol SECONDARY.

Failover automático: cómo el clúster elige un nuevo líder

Esta es la ventaja clave de MySQL Group Replication frente a la replicación clásica. Cuando el nodo primario no está disponible, el grupo inicia las elecciones automáticamente:

1. Los nodos restantes detectan la pérdida de conexión con el primario mediante el mecanismo de detección de fallos (el tiempo de espera se configura con el parámetro group_replication_member_expel_timeout, por defecto 5 segundos).
2. El grupo verifica si existe quórum. Si dos de tres nodos están disponibles, hay quórum.
3. Se selecciona un nuevo primario entre los nodos secundarios según su peso: se tienen en cuenta group_replication_member_weight (prioridad, 50 por defecto) y la versión de MySQL. El nodo con mayor peso se convierte en primario.
4. El nuevo primario pasa al modo lectura-escritura; los secundarios permanecen en solo lectura.
5. Todo esto ocurre sin intervención del administrador, generalmente en 10–30 segundos.

Para gestionar la prioridad en las elecciones, define el peso de forma explícita:

-- En node2: aumentamos la prioridad para el primario preferido
SET GLOBAL group_replication_member_weight = 70;

-- En node3: dejamos la prioridad estándar
SET GLOBAL group_replication_member_weight = 50;

Monitoreo del estado del grupo

MySQL Group Replication está profundamente integrado con performance_schema. Las tablas principales para el monitoreo son:

• performance_schema.replication_group_members — estado y rol de cada nodo.
• performance_schema.replication_group_member_stats — estadísticas de transacciones: cola de certificación, conflictos, latencias.
• performance_schema.replication_connection_status — estado del canal de recuperación.

-- Estado general del grupo
SELECT
  MEMBER_HOST,
  MEMBER_PORT,
  MEMBER_STATE,
  MEMBER_ROLE,
  MEMBER_VERSION
FROM performance_schema.replication_group_members
ORDER BY MEMBER_ROLE;

-- Estadísticas de certificación y cola de conflictos
SELECT
  MEMBER_ID,
  COUNT_TRANSACTIONS_IN_QUEUE,
  COUNT_TRANSACTIONS_CHECKED,
  COUNT_CONFLICTS_DETECTED,
  COUNT_TRANSACTIONS_ROWS_VALIDATING
FROM performance_schema.replication_group_member_stats;

Para alertas automáticas, integra estas consultas en Prometheus mediante mysqld_exporter o configura verificaciones periódicas con tus propios scripts de monitoreo. Las métricas críticas para las alertas son: MEMBER_STATE != 'ONLINE' y el aumento de COUNT_CONFLICTS_DETECTED.

Problemas habituales y cómo resolverlos

Split-brain y particionamiento de red

Si la red entre los nodos se divide de tal manera que ningún subgrupo tiene quórum, Group Replication pone todos los nodos en modo ERROR y se niega a aceptar escrituras. Este es el comportamiento correcto: es mejor detener las escrituras que permitir la divergencia de datos. Tras restaurar la red, es necesario reiniciar los nodos:

STOP GROUP_REPLICATION;
START GROUP_REPLICATION;

Conflictos de transacciones en modo multi-primary

En el modo multi-primary, Group Replication utiliza un mecanismo optimista de certificación: una transacción se revierte si otro nodo confirmó antes un cambio en la misma fila. La aplicación debe manejar el error ERROR 1180 (HY000): Got error 149 y reintentar la transacción. Minimiza los conflictos mediante el sharding de consultas por nodos o pasando al modo single-primary.

El nodo no puede unirse al grupo

Una causa frecuente es la divergencia de los conjuntos GTID. Si un nodo estuvo inactivo durante mucho tiempo, al iniciarse Group Replication activa el mecanismo de recuperación distribuida: el nodo copia los datos faltantes desde un nodo donante mediante clonación (si el plugin mysql_clone.so está instalado) o a través de los binlogs. Asegúrate de que el plugin de clonación esté instalado en todos los nodos:

INSTALL PLUGIN clone SONAME 'mysql_clone.so';
GRANT CLONE_ADMIN ON *.* TO 'repl'@'%';

Integración con MySQL Router

La aplicación no debería saber qué nodo es el primario en cada momento. MySQL Router es un proxy ligero de Oracle que enruta automáticamente las solicitudes: las operaciones de escritura se dirigen al primario y las de lectura, a los secundarios. Está incluido en MySQL Shell y se distribuye de forma gratuita.

Configuración mínima de MySQL Router para un clúster de Group Replication:

# /etc/mysqlrouter/mysqlrouter.conf

[DEFAULT]
logging_folder = /var/log/mysqlrouter
runtime_folder = /run/mysqlrouter

[logger]
level = INFO

# Puerto de escritura — enruta solo al PRIMARY
[routing:gr_rw]
bind_address = 0.0.0.0
bind_port = 6446
destinations = metadata-cache://mycluster/?role=PRIMARY
routing_strategy = first-available
protocol = classic

# Puerto de lectura — balancea entre los SECONDARY
[routing:gr_ro]
bind_address = 0.0.0.0
bind_port = 6447
destinations = metadata-cache://mycluster/?role=SECONDARY
routing_strategy = round-robin-with-fallback
protocol = classic

[metadata_cache:mycluster]
cluster_type = gr
router_id = 1
user = router_user
metadata_cluster = mycluster
ttl = 0.5
auth_cache_ttl = -1

Tras un failover automático, MySQL Router detectará el cambio de primario en el tiempo definido por el parámetro ttl (0,5 segundos en el ejemplo) y comenzará a dirigir las escrituras al nuevo nodo primario. La aplicación se reconecta de forma transparente.

Para inicializar los metadatos del clúster en MySQL Router, utiliza MySQL Shell:

mysqlsh --uri root@node1.example.com:3306 -- dba configureInstance
mysqlsh --uri root@node1.example.com:3306 -- dba createCluster mycluster
mysqlrouter --bootstrap root@node1.example.com:3306 --directory /etc/mysqlrouter --conf-use-gr-notifications

Comparación con MySQL InnoDB Cluster y Galera Cluster

MySQL InnoDB Cluster es una capa adicional sobre Group Replication que incluye MySQL Shell (gestión del clúster mediante la API de JavaScript/Python) y MySQL Router. En esencia, InnoDB Cluster utiliza Group Replication como capa de transporte. Si deseas gestionar el clúster a través de una API cómoda y estás dispuesto a usar MySQL Shell, elige InnoDB Cluster. Si prefieres una pila mínima con SQL puro, opta por Group Replication directamente.

Galera Cluster (Percona XtraDB Cluster / MariaDB Galera) es una implementación independiente de replicación síncrona multi-primary que surgió antes que Group Replication. Galera está probado durante años, funciona bien en modo multi-primary, pero requiere la instalación de paquetes de terceros (Percona o MariaDB) y tiene su propio ecosistema. Group Replication es la solución oficial de Oracle, integrada en MySQL 8.x, lo que simplifica el soporte y el licenciamiento. En 2026, para nuevos proyectos en MySQL «vanilla», la elección de Group Replication es la más lógica.

Diferencias clave en resumen:

• Group Replication: integrado en MySQL 8.x, mantenido por Oracle, single/multi-primary, consenso Paxos.
• InnoDB Cluster: Group Replication + MySQL Shell + MySQL Router, gestión más sencilla.
• Galera: paquete de terceros, multi-primary maduro, ecosistema diferente.

Conclusión: cuándo elegir Group Replication

MySQL Group Replication es la opción correcta si:

• Usas MySQL 8.0+ y quieres failover automático sin herramientas externas.
• Los requisitos de SLA no permiten intervención manual ante un fallo del primario.
• Gestionas la infraestructura de forma independiente y no quieres migrar a bases de datos cloud gestionadas.
• La carga es predominantemente de lectura con escritura moderada (modo single-primary).

Cuándo considerar alternativas:

• Si necesitas el máximo rendimiento de escritura con mínimos conflictos, Galera en modo multi-primary puede estar mejor ajustado para ese escenario.
• Si ya utilizas el ecosistema de Percona o MariaDB.
• Si la latencia de red entre nodos supera los 10–15 ms: el consenso síncrono comenzará a afectar de forma notable a la latencia de escritura.

En 2026, MySQL Group Replication combinado con MySQL Router representa una solución production-ready para la alta disponibilidad de MySQL, que no requiere ni servicios cloud ni herramientas externas como Orchestrator. Invierte tiempo en la configuración inicial correcta, configura el monitoreo a través de performance_schema, y tu clúster se recuperará por sí solo sin necesidad de un ingeniero de guardia.