MySQL主从复制的监控核心是确认复制是否正常运行、有无延迟、是否存在错误。重点看三个指标：IO线程是否连接主库、SQL线程是否在执行、Seconds_Behind_Master是否持续为0或稳定波动。
关键状态字段怎么看
在从库执行
SHOW SLAVE STATUS\G，重点关注以下几项： Slave_IO_Running：必须为
Yes，表示从库能连上主库并接收binlog Slave_SQL_Running：必须为
Yes，表示从库正在回放relay log Seconds_Behind_Master：数值越小越好，0 表示基本实时；若持续大于 60 秒需警惕 Relay_Log_Space：过大可能说明SQL线程卡住，或主库写入压力大 Last_IO_Errno / Last_SQL_Errno：非0即出错，要立刻查错因（如主键冲突、表不存在）
用命令+脚本做基础巡检
可写简单Shell脚本定时检查关键字段，例如：
mysql -uuser -ppass -e "SHOW SLAVE STATUS\G" | grep -E "Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master|Last_IO_Errno|Last_SQL_Errno"
配合
crontab每分钟执行一次，异常时发邮件或写日志。注意避免高频查询影响性能，生产环境建议5–30秒间隔更稳妥。
引入监控系统做长期跟踪
推荐用Prometheus + mysqld_exporter采集指标，再通过Grafana可视化：
监控mysql_slave_status_seconds_behind_master趋势图，设阈值告警（如 > 120s 持续2分钟） 跟踪
mysql_slave_status_slave_io_running和
mysql_slave_status_slave_sql_running的布尔状态变化 结合
mysql_global_status_commands_total{command="com_commit"} 对比主从QPS，辅助判断复制压力
识别常见假“正常”陷阱
有些状态看似OK，实则隐患已埋下：
Seconds_Behind_Master: NULL：不是延迟大，而是SQL线程没启动或刚启动，需结合
Slave_SQL_Running判断
Seconds_Behind_Master: 0但
Relay_Log_Pos长期不更新：可能是主库没新写入，也可能是IO线程假连（实际断开但未超时） 启用GTID后，
Retrieved_Gtid_Set和
Executed_Gtid_Set不一致：说明部分事务没执行，不能只看
Seconds_Behind_Master
不复杂但容易忽略的是持续观察和横向对比——单次检查只能看快照，结合历史趋势和主从负载才能真正定位问题根源。
