SQL主从延迟如何监控_关键指标与告警思路【技巧】

主从延迟监控需综合多项指标：必须每小时检查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 做真实延迟校准：

标签： mysql 微信 企业微信 ssl ai ios 路由 钉钉