DBAtlas · Atlas de operações de banco de dados

Verificar a saúde do InnoDB Cluster / Group Replication

MySQLInnoDB Cluster

Comando

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

O que faz

Mostra o estado geral do cluster (OK / OK_NO_TOLERANCE / NO_QUORUM), o primário, o estado de cada membro e as filas de certification / applier; as filas revelam qual membro está atrasado e o risco de flow control.

Quando usar

Antes e depois de toda intervenção; em alertas, lentidão de gravações ou quando um membro mostra RECOVERING / ERROR / UNREACHABLE.

Atenção

O statusText deve dizer 'can tolerate up to ONE failure' (3 membros). Com NO_QUORUM as gravações param; use forceQuorumUsingPartitionOf apenas quando tiver certeza de que a outra partição está fora, senão ocorre split-brain. Um membro cujo apply_queue continua crescendo dispara o flow control e deixa as gravações no primário lentas. Um RECOVERING longo significa que a recuperação por clone / incremental está rodando; para ERROR verifique o error log e tente cluster.rejoinInstance(). Caracteres especiais em senhas (#, @) devem ser codificados em URL na URI (# → %23).

Abrir no DBAtlas →

Relacionados