凌晨告警响起时，主库写入已恢复，副本却落后十二分钟。请求能提交，连接却不敢切：延迟可能不在网络，而在副本收到日志后仍堵在回放队列。只看心跳或一次延迟值，容易把“能连通”误判成“数据已追平”。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：richproxies（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
先看主库提交。事务返回成功，只表示提交记录已按同步级别写入主库事务日志，并不代表副本已收到或执行。排查要分开记录提交响应、日志生成位点和持久化确认；主库刷盘变慢时，提交延迟先升，副本却可能暂时平稳，因为新日志还没送出。
若发送位点前进快、接收位点落后，问题多在链路、拥塞或接收落盘；若接收已追平而回放位点不动，瓶颈就在副本应用阶段。常见原因包括长事务持锁、并行复制线程不足、存储抖动，以及大事务无法拆分。
并行复制不是线程越多越快。多个线程会争用热点表、索引页和磁盘带宽；日志生成速率长期超过回放吞吐，队列只会增长。把发送、接收、回放三个位点放到同一时间轴，标出停顿位置，才能区分网络慢与应用慢。
判断切换前，先统一复制位点口径：比较主库当前位点、副本已接收位点和已回放位点，并核对最新事务。不要直接用两台机器的墙上时钟相减，时钟偏差会制造假延迟；固定表抽样也看不到刚提交的数据。
可设两级延迟水位。计划切换的初始门槛是总延迟不超过5秒、接收与回放差不超过2秒、队列停止增长，并连续满足10分钟；该数值须按峰值写入压测。若延迟超过60秒、连续3分钟上升，或仍有长事务未回放，则判定禁止切库，先修复或重建副本。
持续监控应保留主库提交响应、事务日志生成速率、发送与接收位点差、接收与回放位点差、并行回放队列长度、每秒回放吞吐。重点看延迟斜率：短暂尖峰可观察，持续抬升说明处理能力不足。真正切流还要确认关键事务可见、回放线程健康，并保留人工确认。
常见坑是只看网络 RTT、只看写入成功，或延迟刚下降就立即切流。异步复制即使低延迟也不等于故障时零丢失；若要求零 RPO，应采用带多数确认的同步复制，并在切换前验证新主身份。若节点由随身服务器统一管理，可把位点差、水位和队列趋势集中告警，但自动切换仍应设置人工闸门。
进一步看延迟，不能只盯秒数。先在主库记录 复制位点 和 事务日志 位点，再到备库查询已经应用的位点；两者差值只能说明队列积压，不能直接等同于用户看到的业务滞后。大事务、外键检查、索引维护和磁盘抖动，都可能让备库已经“接到日志”，却尚未完成提交。
为了判断延迟发生在哪一层，可连续采集三个时间：主库提交时间、位点生成时间、备库应用完成时间。若大量事务集中在同一时间点提交，应检查单线程写入；若位点持续前进但完成时间不动，应检查 并行复制 的 worker 是否被长事务阻塞；若应用位点本身不动，则优先排查网络、日志接收线程和磁盘 I/O。
延迟水位应按业务可接受阈值设置，而不是固定照搬监控告警值。例如复制延迟 30 秒，但最大未提交事务已运行 10 分钟，切换风险仍可能更高。还要把位点差、落后秒数和大事务年龄联合起来看，避免低延迟掩盖尚未完成的事务。
常见误区包括：只看 Seconds_Behind_Master 就认定复制健康；把网络往返时间当作应用延迟；忽略大事务在主库提交后尚未在备库落地的风险；以及切换前没有验证备库能否接管最新写入。
执行前先完成以下检查：
① 在主、备库同时保存复制位点与时间戳，连续采样至少三个高峰周期；
② 执行 SHOW REPLICA STATUS，检查所有复制线程和 worker，确认没有长时间等待、报错或被大事务卡住；
③ 查询备库最长运行事务、未提交事务及大事务年龄，并核对日志接收与应用线程状态；
④ 分别测试网络往返、日志落盘和事务重放耗时，区分链路瓶颈与 SQL 重放瓶颈；
⑤ 预演一次只读切换，验证 故障切换判定 所需的数据新鲜度、应用连接和回滚方案。
只有当复制位点接近目标、延迟水位持续低于阈值、最长事务年龄处于安全范围，并且只读验证通过时，才应把备库提升为主库。若位点差持续扩大、worker 无进展或关键表校验不一致，应立即停止切换，并回到日志接收、网络和存储层继续定位。
