Comprobar la salud de InnoDB Cluster / Group Replication
MySQLInnoDB ClusterComando
# Shell: topology, primary, fault tolerance, lag
mysqlsh icadmin@db1:3306 -- cluster status --extended=1
mysqlsh icadmin@db1:3306 -- cluster list-routers
-- SQL: group members and queues from any member
SELECT m.MEMBER_HOST, m.MEMBER_PORT, m.MEMBER_STATE, m.MEMBER_ROLE, m.MEMBER_VERSION,
s.COUNT_TRANSACTIONS_IN_QUEUE AS certify_queue,
s.COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE AS apply_queue,
s.COUNT_CONFLICTS_DETECTED AS conflicts
FROM performance_schema.replication_group_members m
JOIN performance_schema.replication_group_member_stats s ON s.MEMBER_ID = m.MEMBER_ID
ORDER BY m.MEMBER_ROLE, m.MEMBER_HOST;Qué hace
Muestra el estado general del clúster (OK / OK_NO_TOLERANCE / NO_QUORUM), el primario, el estado de cada miembro y las colas de certificación / applier; las colas revelan qué miembro va retrasado y el riesgo de flow control.
Cuándo usarlo
Antes y después de cada intervención; ante alertas, ralentizaciones de escritura o cuando un miembro muestra RECOVERING / ERROR / UNREACHABLE.
Precaución
statusText debería decir 'can tolerate up to ONE failure' (3 miembros). Con NO_QUORUM las escrituras se detienen; use forceQuorumUsingPartitionOf solo cuando esté seguro de que la otra partición está caída, o tendrá split-brain. Un miembro cuyo apply_queue no deja de crecer dispara el flow control y ralentiza las escrituras en el primario. Un RECOVERING prolongado significa que se está ejecutando un clone / recuperación incremental; ante ERROR revise el error log e intente cluster.rejoinInstance(). Los caracteres especiales de las contraseñas (#, @) deben codificarse en URL en la URI (# → %23).