如何监控主从复制链路的健康状态_Zabbix监控与IO/SQL线程检查

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