基础篇：主从延迟的核心监控指标与度量标准

基础篇：主从延迟的核心监控指标与度量标准

上周深夜收到告警，某业务库主从延迟突然飙到300秒。业务方电话直接打到我这儿：“补货单同步卡住了，仓库那边已经乱套！”登上从库一看，Seconds_Behind_Master显示为0，但业务时间戳比对确实差了五分钟。这个矛盾值让我意识到——很多团队对主从延迟的理解，还停留在那个看似直观却可能骗人的数字上。

监控指标的三重境界

第一重：官方标准指标

打开从库执行SHOW SLAVE STATUS\G，你会看到这几个关键字段：

Slave_IO_Running: Yes-- IO线程活着不代表没延迟Slave_SQL_Running: Yes-- SQL线程活着也不代表同步及时Seconds_Behind_Master:0-- 最常用的指标，但可能说谎

Seconds_Behind_Master的计算原理很简单：比较从库SQL线程当前执行的event时间戳与从库系统时间差值。但这里有个坑——如果主库机器时间比从库慢，这个值可能显示为0甚至负数！我见过生产环境主从时间差2秒，延迟监控完全失灵的案例。

更可靠的判断方法是直接检查binlog位置：

Master_Log_File: mysql-bin.000123Read_Master_Log_Pos:19432567-- IO线程读到的主库位置Relay_Master_Log_File: mysql-bin.000122Exec_Master_Log_Pos:19412345-- SQL线程执行到的位置

这两个位置差就是实实在在的延迟事件数。写个脚本定期采集这两个值，比单纯看Seconds_Behind_Master靠谱得多。