MySQL主从复制监控核心是确认复制正常、无延迟、无错误，重点检查IO线程连接、SQL线程执行及Seconds_Behind_Master是否稳定；需关注SHOW SLAVE STATUS中的Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master、Relay_Log_Space、Last_IO_Errno/Last_SQL_Errno等字段，避免假“正常”陷阱，并结合脚本巡检与Prometheus+Grafana长期跟踪。
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
不复杂但容易忽略的是持续观察和横向对比——单次检查只能看快照，结合历史趋势和主从负载才能真正定位问题根源。
