查MySQL主从复制状态应执行SHOW SLAVE STATUS\G，重点检查Slave_IO_Running和Slave_SQL_Running是否均为Yes，任一为No即复制中断；Seconds_Behind_Master为NULL表明SQL线程已停止。
怎么查 MySQL 主从复制的 IO 和 SQL 线程是否在运行
主从复制挂了，第一反应不是翻日志，而是直接看两个线程状态——Slave_IO_Running 和 Slave_SQL_Running。它们只要有一个是 NO，链路就断了。
实操建议：
- 登录从库执行
SHOW SLAVE STATUS\G，重点盯住这两行输出，别被其他几十行字段带偏 - 注意
Seconds_Behind_Master为NULL时，往往意味着 SQL 线程已停止（不是延迟大，是彻底卡死） - 如果
IO_Running是Connecting，说明从库连不上主库——检查Master_Host、网络、主库bind_address和防火墙 - SQL 线程报错常见于主库执行了从库不兼容的操作，比如没主键的表被更新，错误号会写在
Last_SQL_Errno和Last_SQL_Error里
Zabbix 怎么抓取 Slave_IO_Running 这类状态值
Zabbix 本身不理解 MySQL 复制状态，得靠自定义监控项把 SHOW SLAVE STATUS 的结果“掰开”喂给它。
实操建议：
- 用 Zabbix Agent 的
UserParameter配置，例如：UserParameter=mysqld.replica.io_running,mysql -Nse "SHOW SLAVE STATUS\G" 2>/dev/null | grep "Slave_IO_Running:" | awk '{print $2}' - 必须加
-N（禁用列名）和-s（跳过表格格式），否则 grep 会匹配失败 - 别用
mysql -e "SHOW SLAVE STATUS"，因为默认输出带横线分隔符，grep容易误匹配 - Zabbix item 的类型选
Text或Character，别设成Numeric——状态是Yes/No，不是数字
为什么 Zabbix 显示 “OK” 但实际复制已经延迟数小时
IO_Running 和 SQL_Running 都是 Yes，不代表复制健康。真正危险的是 Seconds_Behind_Master 持续上涨，而 Zabbix 默认不监控它，或只设了个静态阈值（比如 > 60 秒告警），忽略了业务峰值期的合理波动。
实操建议：
- 把
Seconds_Behind_Master单独做成一个 Zabbix item，类型设为Numeric (unsigned)，单位秒 - 告警策略不能只看绝对值：对写入密集型从库，延迟 300 秒可能正常；对低频更新库，延迟 60 秒就得立刻响应
- 配合监控
Exec_Master_Log_Pos和Read_Master_Log_Pos的差值，能判断 IO 是否拉取滞后（差值大 + 延迟高 = 主库写太快，从库网络或磁盘慢） - 避免用
SHOW SLAVE STATUS全量查询再解析——每秒一次太重，Zabbix agent 内部应缓存最近一次结果，或改用 performance_schema 表（如replication_connection_status）替代
从库重启后 Zabbix 监控项突然全失效
不是 Zabbix 出问题，是 MySQL 重启后，SHOW SLAVE STATUS 在复制未启动前返回空，导致所有基于它的 UserParameter 解析失败，Zabbix 收到空值或报错，触发异常状态。
实操建议：
- 在 UserParameter 脚本末尾加兜底逻辑，例如：
|| echo "NULL"，确保总有输出，避免 Zabbix 报NOTSUPPORTED - 检查 Zabbix agent 日志，搜索
cannot parse或timeout，常因 MySQL 启动慢、agent 超时 3 秒导致采集失败 - 从库启动脚本里加个等待环节：
until mysql -e "SHOW SLAVE STATUS\G" >/dev/null 2>&1; do sleep 2; done，再启动 Zabbix agent - 不要依赖
Slave_SQL_Running_State这类字符串字段做告警——它内容不稳定（如 “Reading event from the relay log” / “System lock”），容易误判
真正难的不是取值，是区分“瞬时抖动”和“持续恶化”。比如 Seconds_Behind_Master 从 0 跳到 120 又回落，可能是单条大事务；但如果连续 5 分钟 > 300，大概率是 relay log 写满、磁盘 IO 瓶颈或 SQL 线程被锁表卡住——这时候得切到 SHOW PROCESSLIST 和 information_schema.INNODB_TRX 查现场。
