DBAtlas · Database operations atlas

Check InnoDB Cluster / Group Replication health

MySQLInnoDB Cluster

Command

# 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;

What it does

Shows overall cluster state (OK / OK_NO_TOLERANCE / NO_QUORUM), the primary, each member's state and the certification / applier queues; the queues reveal which member lags and the flow-control risk.

When to use it

Before and after every intervention; on alerts, write slowdowns, or when a member shows RECOVERING / ERROR / UNREACHABLE.

Caution

statusText should say 'can tolerate up to ONE failure' (3 members). With NO_QUORUM writes stop; use forceQuorumUsingPartitionOf only when you are certain the other partition is down, otherwise you get split-brain. A member whose apply_queue keeps growing triggers flow control and slows writes on the primary. A long RECOVERING means clone / incremental recovery is running; for ERROR check the error log and try cluster.rejoinInstance(). Special characters in passwords (#, @) must be URL-encoded in the URI (# → %23).

Open in DBAtlas →

Related