MySQL集群监控需确认节点在线（MEMBER_STATE=ONLINE）、角色正常（PRIMARY/SECONDARY）、同步无延迟（Seconds_Behind_Master≈0）、资源无瓶颈（连接数、缓冲池命中率等），并借助Zabbix、Prometheus或云平台实现自动化告警。
MySQL集群的运行状态监控，核心在于确认节点存活、数据同步正常、组内角色稳定以及资源无瓶颈。不能只看单个实例是否“在跑”，而要关注整个集群的协作健康度。
确认集群节点在线与角色状态
对于使用MySQL Group Replication（MGR）或InnoDB Cluster的环境，首先要验证各节点是否已加入集群且处于活跃状态：
- 登录任一节点，执行：
SELECT * FROM performance_schema.replication_group_members;
检查MEMBER_STATE是否为ONLINE，MEMBER_ROLE是否符合预期（如 PRIMARY 或 SECONDARY） - 若某节点显示
RECOVERING或OFFLINE，说明同步异常或未成功加入；ERROR状态需立即查错误日志 - 配合系统命令验证进程：如
systemctl status mysqld或ps aux | grep mysqld，确保 MySQL 进程本身未崩溃
检查主从复制与组内同步延迟
即使所有节点都在线，数据不同步也会导致服务不可靠：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 对 MGR 集群，重点看：
SHOW REPLICA STATUS\G（MySQL 8.0.22+）或 SHOW SLAVE STATUS\G（兼容旧版）
确认Replica_IO_Running和Replica_SQL_Running均为Yes - 检查同步延迟：
Seconds_Behind_Master应接近 0；持续大于 30 秒需排查网络、大事务或从库负载 - 查看组复制通道状态：
SELECT * FROM performance_schema.replication_connection_status;
确认CHANNEL_NAME为group_replication_applier且SERVICE_STATE是ON
监控关键性能与资源指标
集群稳定性不仅依赖复制逻辑，还受内存、磁盘、连接数等资源制约：
- 连接与线程：
SHOW GLOBAL STATUS LIKE 'Threads_connected';
结合max_connections配置判断是否接近上限；Threads_running持续 > 50 可能存在阻塞 - 缓冲池与缓存：
SHOW ENGINE INNODB STATUS\G 中关注Buffer pool hit rate（建议 >99%）和pending log writes（过高说明 I/O 压力大） - 慢查询与错误：
开启并定期分析慢查询日志；检查Aborted_clients、Aborted_connects是否突增，反映连接异常或认证失败
用工具实现自动化监控与告警
人工巡检无法满足高可用要求，推荐以下轻量到企业级方案：
-
Zabbix：配置 MySQL 模板，通过自定义脚本调用
mysql -e "SELECT MEMBER_STATE FROM..."判断集群状态，设置阈值告警 -
Prometheus + mysqld_exporter：采集
mysql_group_replication_member_state、mysql_slave_status_seconds_behind_master等指标，配合 Grafana 可视化 - 云平台集成：如阿里云 PolarDB、腾讯云 TDSQL 已内置集群拓扑图、同步延迟热力图和自动故障切换日志，可直接启用
