MySQL主从复制延迟监控：避开Seconds_Behind_Master的“甜蜜陷阱”

查 Seconds_Behind_Master 为什么不准？

说起监控MySQL主从延迟，Seconds_Behind_Master（SBM）这个指标几乎是所有人的第一反应。它看起来直观又方便，对吧？但真相是，它可能是监控体系里最会“说谎”的家伙。你经常会发现它显示为0或者NULL，尤其是在启用了GTID、并行复制，或者IO线程稍有风吹草动的时候。这个值本质上只反映了SQL线程处理relay log中最后一个事件的时间差，至于数据在网络中跋涉的耗时、在磁盘上刷写的等待，或者一个大事务在从库上吭哧吭哧执行的阻塞，它统统视而不见。

• 当它显示为NULL时，情况往往不是“没有延迟”，而是更糟——通常意味着IO线程已经停止运行（Sla ve_IO_Running: No），连主库的日志都收不到了。
• 在主库设置binlog_order_commits=OFF，或者从库使用sla ve_parallel_workers > 0进行并行复制时，SBM很可能长期稳定在0，给人一种“天下太平”的假象，而实际的延迟可能正在悄悄累积。
• 如果主从服务器部署在不同时区，系统时间没有同步，这个值甚至会出现负数或毫无规律的跳变，用它来设置告警阈值，无异于在流沙上盖房子。

Prometheus 怎么拿到真实延迟？用 mysqld_exporter 的 mysql_sla ve_status_seconds_behind_master 不够

既然SBM不可靠，那用Prometheus抓取它总行了吧？很遗憾，官方mysqld_exporter默认采集的正是这个Seconds_Behind_Master。直接用它配置告警规则，相当于把“假数据”供起来当圣旨，监控系统也就成了摆设。我们必须寻找更可靠的延迟数据源，这里有两个主流思路：

• 基于GTID比对：理论上，可以通过对比已执行和已接收的GTID集合来计算延迟。但注意，像SELECT TIMESTAMPDIFF(SECOND, (SELECT @@gtid_executed), (SELECT @@gtid_purged FROM ...))这样的查询是行不通的，因为@@gtid_purged是主库的信息，从库根本看不到。正确的做法需要关联查询performance_schema中的replication_connection_configuration和replication_applier_status_by_coordinator表，获取未执行的GTID集合，再去比对主库SHOW MASTER STATUS的输出——这通常意味着需要额外从主库拉取指标，架构上稍显复杂。
• 更实用的时间戳心跳法：这是经过大量实践验证的可靠方案。在主库定期（比如每秒）向一张专用的心跳表（例如monitor.heartbeat）写入当前时间戳。然后，在从库上执行一个简单的查询：SELECT UNIX_TIMESTAMP() - UNIX_TIMESTAMP(ts) FROM monitor.heartbeat，差值就是近乎真实的复制延迟。Prometheus可以通过配置mysqld_exporter的自定义查询文件（queries.yaml）来暴露这个计算结果，指标名可以设为mysql_sla ve_heartbeat_delay_seconds。

告警规则怎么写才不误报？

拿到了真实延迟指标，是不是直接设置一个“大于60秒就告警”的规则就可以了？别急，这样做的结果很可能是告警风暴。数据库延迟存在瞬时抖动再正常不过了，比如主库突然来个批量导入，或者从库的磁盘IO临时打满，出现几秒到十几秒的延迟波动无需惊慌。告警的关键，在于区分“短暂的性能毛刺”和“持续性的复制恶化”。

• 使用聚合，告别单点：用a vg_over_time(mysql_sla ve_heartbeat_delay_seconds[5m]) > 60来代替mysql_sla ve_heartbeat_delay_seconds > 60。这意味着，只有当5分钟内的平均延迟持续超过60秒时才触发告警，可以有效过滤掉那些瞬间的尖峰。
• 加上状态判断，让告警更智能：增加一层过滤条件，只有当mysql_sla ve_io_running == 1且mysql_sla ve_sql_running == 1时，才计算延迟。这能避免一种尴尬情况：IO线程早就断开了，复制已停止，但延迟时间却卡在一个很大的数值（比如3600秒）不动，持续触发无意义的告警。
• 分级告警，按库施策：不同业务数据库对延迟的容忍度天差地别。核心交易库可能要求延迟严格控制在30秒内，而用于离线分析的报表库放宽到300秒也未尝不可。可以利用Prometheus的标签功能，通过label_values和relabel配置，为不同实例（instance）或数据库（schema）设置差异化的告警阈值。

为什么心跳表更新频率不能低于 10 秒？

心跳表方案看似简单，但细节决定成败。更新频率就是个需要权衡的关键点：太频繁（比如每秒）会给高负载的主库增加不必要的写压力，尤其是当你有几十个从库都在轮询时；太慢（比如每分钟）又会导致监控灵敏度下降，告警严重滞后。经过众多生产环境的实测，将更新间隔设置在10秒左右是一个比较好的平衡点。

• 优化写入操作：建议使用INSERT ... ON DUPLICATE KEY UPDATE ts=NOW()语句，并为心跳表设置一个固定的主键（如id = 1）。这样每次更新都是原地修改同一行，可以避免产生大量的binlog事件，减轻复制链路本身的负担。
• 注意语句选择：如果主库的QPS已经很高，使用REPLACE INTO可能会触发更多的锁竞争，反而不如直接用UPDATE。但务必确保心跳表有合适的主键或唯一索引，否则UPDATE会退化为恐怖的全表扫描。
• 警惕时间函数陷阱：绝对不要直接使用NOW()函数插入时间。如果从库开启了log_sla ve_updates，这个NOW()会被记录为从库的本地时间，导致延迟计算完全失真。应该使用SYSDATE()函数，或者更稳妥的方式，由应用程序层获取精确的时间戳后显式写入。

说到底，真实的复制延迟永远隐藏在从主库到从库那条漫长链路中最薄弱的环节里，绝非查看一个简单的状态字段就能下定论。可靠的主从延迟监控，必须是一个完整的闭环：精心设计的心跳表提供真实数据源，自定义的exporter查询将其转化为可靠指标，再配上带有状态过滤和聚合逻辑的智能告警规则。这三环，缺了任何一环，你的监控都只能做到“看起来在线”，而非真正的“可知可控”。