复制延迟监控是什么
复制延迟是主备之间数据落后的时间量，它同时决定两件事：故障切换时可能丢多少数据（数据丢失窗口），以及备库能否被当作可读副本来分流。延迟不是稳定值：批量写入、大事务、网络抖动都会把它推高，因此要持续观测并设阈值告警，而不是在设计文档里写一个平均值完事。
基本信息
| 常见指标 | MySQL 的 Seconds_Behind_Source、PostgreSQL 的重放时间戳差值、GTID 或位点差集 |
|---|---|
| 指标性质 | 过程指标（延迟秒数）与结果指标（业务时间戳差）要一起看 |
| 告警口径 | 按业务 RPO 设定，例如 RPO 5 分钟则延迟超过 1 分钟即告警 |
| 基线概念 | 批量作业时段的正常延迟可能是平峰的数倍，阈值要结合业务节奏 |
典型使用场景
- 容灾切换前确认：延迟在可接受范围内才敢切换，避免丢太多数据
- 读写分离决策：延迟超阈值时把只读流量从备库摘除，防止读到过期数据
- 批量导入护航：大事务期间盯延迟，必要时改为分批写入
- 复制链路巡检：确认两个复制线程都在运行，而不是只看一个延迟数字
- RPO 兑现证明：用延迟与业务时间戳记录支撑对外承诺
常见观测手段
常见观测手段
# MySQL：从库状态里的延迟字段
mysql -e "SHOW REPLICA STATUS\G" | grep -E "Replica_IO_Running|Replica_SQL_Running|Seconds_Behind_Source"
# 大事务场景看位点差集比看秒数更接近真实积压
mysql -e "SHOW REPLICA STATUS\G" | grep -E "Retrieved_Gtid_Set|Executed_Gtid_Set"
# PostgreSQL：视图中的重放延迟
psql -c "SELECT now() - pg_last_xact_replay_timestamp() AS replay_lag;"
# 更可靠的做法：在源库打心跳表，测量端到端延迟
mysql -e "INSERT INTO monitor.heartbeat(ts) VALUES(NOW());"
# 备库侧读出最新心跳时间，与当前时间相减即为端到端延迟延迟指标读法
| 指标 | 含义 | 正常/异常 |
|---|---|---|
| Seconds_Behind_Source | 备侧重放落后主库的秒数估计 | 网络断开时会显示 NULL 或出现误报，不能单独依赖 |
| Retrieved / Executed GTID 差集 | 已拉到与已应用的变更量之差 | 差集持续扩大说明重放跟不上，是更接近真实的积压量 |
| replay 时间戳差值 | PostgreSQL 最近一次重放事务与当前时间的间隔 | 空闲库上该值可能很大，需结合业务节奏解读 |
| 心跳表延迟 | 源库写入时间戳到备库可读的时间差 | 端到端最直观的指标，建议作为主告警依据 |
延迟要跟着业务节奏看基线：夜间批量导入时段的正常延迟可能是平峰的数倍，用固定阈值会频繁误报，比较稳的做法是分时段设阈值。
复制线程中断时延迟指标可能不升反降，甚至显示为正常值：只看延迟数字不看线程状态，会漏掉『备库早已停止同步』这类严重问题。