DBAtlas · Атлас эксплуатации баз данных

Проверить работоспособность InnoDB Cluster / Group Replication

MySQLInnoDB Cluster

Команда

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

Что делает

Показывает общее состояние кластера (OK / OK_NO_TOLERANCE / NO_QUORUM), primary, состояние каждого участника и очереди certification / applier; очереди показывают, какой участник отстаёт, и риск flow control.

Когда использовать

До и после каждого вмешательства; при алертах, замедлении записи или когда участник показывает RECOVERING / ERROR / UNREACHABLE.

Внимание

statusText должен сообщать 'can tolerate up to ONE failure' (3 участника). При NO_QUORUM запись останавливается; используйте forceQuorumUsingPartitionOf, только если уверены, что другой раздел неработоспособен, иначе получите split-brain. Участник, у которого apply_queue продолжает расти, запускает flow control и замедляет запись на primary. Долгое состояние RECOVERING означает, что выполняется clone / инкрементальное восстановление; при ERROR проверьте журнал ошибок и попробуйте cluster.rejoinInstance(). Специальные символы в паролях (#, @) в URI нужно кодировать (# → %23).

Открыть в DBAtlas →

Связанные материалы