主从延迟监控需综合多项指标：必须每小时检查Slave_IO_Running、Slave_SQL_Running（均为Yes）、Seconds_Behind_Master（≥30秒预警，NULL需紧急处理）、Last_IO_Error/Last_SQL_Error（定位根因）、Relay_Log_Space（持续上涨提示SQL卡顿）；推荐用pt-heartbeat替代Seconds_Behind_Master获取真实延迟；告警分级为黄色（≥30秒持续2分钟）、红色（≥120秒或线程中断）、橙色（≥300秒无下降趋势并自动切流）；可视化需叠加Threads_running、Innodb_row_lock_waits、Binlog_cache_disk_use占比、网络RTT/丢包率、磁盘await等上下文指标。
主从延迟监控不能只盯着一个数字，得看一组相互印证的状态和指标。核心目标是：早发现、准定位、快响应。
关键状态字段必须每小时扫一眼
在从库执行 SHOW SLAVE STATUS\G，重点关注以下五项：
- Slave_IO_Running 和 Slave_SQL_Running：两者都必须为 Yes；任一为 No，说明复制已中断，需立即排查网络、权限或日志损坏。
- Seconds_Behind_Master：数值为 0 表示当前同步正常；持续 ≥30 秒需预警；突增至 NULL 往往意味着 SQL 线程崩溃或 IO 断连。
- Last_IO_Error 和 Last_SQL_Error：错误信息直接暴露根因，比如 “Could not find first log file name in binary log index file” 是主库 binlog 被误删，“Deadlock found when trying to get lock” 则指向从库锁冲突。
- Relay_Log_Space：该值持续上涨且 Seconds_Behind_Master 不降，大概率是 SQL 线程执行卡住（如大事务、全表更新、缺失索引），而非网络慢。
比 Seconds_Behind_Master 更可靠的延迟测量法
Seconds_Behind_Master 是估算值，依赖系统时间且受 SQL 线程暂停影响。生产环境建议用 pt-heartbeat 做真实延迟校准：
- 在主库定时写入带毫秒精度的时间戳（例如每秒一次）到专用心跳表；
- 从库读取该记录，与本地 NOW(3) 比较，得出端到端真实延迟；
- 该方式不受线程停摆、时区偏差、GTID 模式干扰，误差通常
告警阈值设置要分层，不搞一刀切
单一“>60秒就告警”容易误报或漏报，建议按业务敏感度分级：
- 警告级（黄色）：延迟 ≥30 秒且持续 2 分钟 —— 触发企业微信/钉钉通知，提醒值班人员关注；
- 严重级（红色）：延迟 ≥120 秒 或 SQL/IO 线程为 No —— 自动电话+短信双通道告警，并触发自动检查脚本（如查 iostat、show processlist、innodb status）；
- 熔断级（橙色）：延迟 ≥300 秒且无下降趋势 —— 自动将读流量切换至主库（需应用层支持读写分离路由降级）。
可视化监控不能只看曲线，要带上下文
用 Prometheus + MySQL Exporter + Grafana 搭建看板时，除了画 Seconds_Behind_Master 曲线，务必叠加以下关联指标：
- 从库 Threads_running 和 Innodb_row_lock_waits：飙升说明 SQL 执行被锁阻塞；
- 主库 Binlog_cache_use 与 Binlog_cache_disk_use：后者占比高，说明大事务频繁，易引发从库回放慢；
- 网络层 RTT（ping 延迟） 和 丢包率：跨机房部署时，RTT >10ms 或丢包 >0.1% 就可能成为瓶颈；
- 磁盘 %util 和 await（iostat 输出）：若从库 await >20ms，relay log 写入很可能成拖累。
