怎么看 Seconds_Behind_Master
是否真的可靠
很多人只看
Seconds_Behind_Master是不是 0，就认为主从正常——这是最大误区。这个值为 0 只代表 SQL 线程追上了 relay log 的最后一条，不代表数据一致，也不代表没丢事务。
真正要确认健康，得结合多个指标一起看：
Slave_IO_Running和
Slave_SQL_Running必须都是
Yes
Seconds_Behind_Master长期非 0（比如持续 > 60 秒），要查
SHOW PROCESSLIST里 SQL 线程是否卡在某个慢查询或锁等待上 如果
Seconds_Behind_Master是
NULL，说明 IO 线程没连上主库，或主库 binlog 被删了（常见于
expire_logs_days设置过小） 注意：在 GTID 模式下，
Seconds_Behind_Master在从库重启后可能短暂显示
NULL，等 IO 线程重连并拉取新事件后才恢复
用 SHOW SLAVE STATUS\G
查哪些字段不能忽略
执行这条命令后，重点盯住这几个字段，它们比
Seconds_Behind_Master更反映底层状态：
Master_Host和
Master_Port：确认连的是预期的主库，不是误切到其他实例
Relay_Master_Log_File和
Exec_Master_Log_Pos：组合起来表示“当前已执行到主库哪个 binlog 文件和位置”，可与主库的
SHOW MASTER STATUS对比是否滞后
Retrieved_Gtid_Set和
Executed_Gtid_Set（GTID 模式下）：前者是已拉到 relay log 的事务集合，后者是已执行的；两者不等就说明 SQL 线程没跟上，哪怕
Seconds_Behind_Master=0
Last_IO_Errno/
Last_SQL_Errno：非 0 就代表出错了，必须立刻看
Last_IO_Error或
Last_SQL_Error具体内容
为什么 pt-table-checksum
是唯一能验证数据一致性的工具
网络延迟、重复写入、SQL 过滤规则、字符集差异……这些都可能导致主从“看起来在跑”，但数据早已不一致。
SHOW SLAVE STATUS完全无法发现这类问题。
pt-table-checksum是 Percona Toolkit 中专为这事设计的工具，原理是在主库分块计算校验和，并通过复制机制把校验语句传到从库执行，再对比结果： 必须在主库上运行，且账号要有
REPLICATION CLIENT+
PROCESS+
SELECT权限 默认跳过系统库和视图，可通过
--databases指定业务库 若从库报错
1062 Duplicate entry或
1032 Can't find record，说明行级不一致，要用
pt-table-sync修复 不要在业务高峰跑全库校验，加
--chunk-size和
--sleep控制压力
监控脚本里最容易漏掉的三个检查点
自动化检查脚本常只做
SHOW SLAVE STATUS解析，但以下三点不显式判断，等于白监控： 检查
Seconds_Behind_Master是否为
NULL：很多脚本用整数比较，遇到
NULL直接报错或跳过，导致故障沉默 检查
Slave_SQL_Running_State是否卡在
Waiting for dependent transaction to commit（MGR 或并行复制场景），这不算错误状态，但实际已停滞 检查主库 binlog 是否被清理：在从库执行
SELECT MASTER_POS_WAIT('<code>Relay_Master_Log_File', Exec_Master_Log_Pos, 1)，返回
-1就说明主库上对应 binlog 已不存在，复制不可逆中断
复制健康不是单点判断，是 IO 连通性、SQL 执行进度、GTID/position 追踪、数据一致性四层叠加验证。少一层，就可能在线上安静地腐烂一周才暴露。
