测MySQL主从真实延迟不能只看Seconds_Behind_Master，需用pt-heartbeat或NOW(6)时间差法；mysqldump直传易失败，应分段导出+压缩+禁用自动提交；GTID同步要验gtid_executed、重置slave、手动拉binlog；高RTT下需调大超时参数、关闭压缩协议、启用并行复制。
MySQL主从同步时网络延迟怎么测准
光看 SHOW SLAVE STATUS 里的 Seconds_Behind_Master 容易误判——它只反映SQL线程重放延迟，不包含网络传输耗时。真实链路里，binlog从主库写入、到网络发包、再到从库IO线程写入relay log，每段都可能卡住。
实操建议：
- 用
pt-heartbeat工具：在主库定时更新一张心跳表，从库查该行时间戳差值，结果更贴近端到端延迟 - 手动验证法：在主库执行
SELECT NOW(6)，立刻在从库查同一条语句的执行时间差（需确保时钟已用chrony同步） - 避开高峰期测：跨机房同步受带宽抢占影响大，连续测5分钟取P95值比单次结果可靠
mysqldump + 网络直传会卡在哪
直接 mysqldump --host=local ... | mysql --host=cloud... 看似简洁，但实际极易失败——没缓冲、无重试、不压缩，一旦中间断连或云服务器临时限速，整个导入就中断，且无法 resume。
实操建议：
- 必须加
--compress参数，降低传输量（尤其对TEXT/BLOB字段） - 改用分段导出：
mysqldump --where="id BETWEEN 1 AND 100000"配合脚本循环，失败只重跑单段 - 禁用自动提交：
mysql --init-command="SET autocommit=0"，避免长事务阻塞从库复制线程 - 别用管道直连：先
mysqldump > backup.sql，再scp -C backup.sql user@cloud:/tmp/，可控性高得多
GTID模式下跨网络同步的坑
开启 gtid_mode=ON 后，主从切换看似简单，但私有云环境常因防火墙策略或DNS解析问题导致 CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1 卡在“Waiting for master to send event”状态，日志里却只报 Got fatal error 1236，不指明是网络还是权限问题。
实操建议：
- 先确认
show global variables like 'gtid_executed'在主从两端能正常返回，否则说明GTID未真正启用 - 检查
master_info_repository = 'TABLE'，文件模式在跨网络重启后易丢位点 - 首次同步前，在从库执行
RESET SLAVE ALL，清空旧的master.info和relay-log.info，避免残留配置干扰 - 用
mysqlbinlog --read-from-remote-server手动拉一段binlog测试连通性，比盲等START SLAVE更早暴露问题
如何让同步扛住300ms RTT波动
本地到私有云常见RTT在80–350ms之间跳变，MySQL默认的 slave_net_timeout = 60 和 net_read_timeout = 30 会导致频繁重连、IO线程反复中断，继而引发relay log不连续、Slave_SQL_Running_State 卡在“Reading event from the relay log”。
实操建议：
- 调高
slave_net_timeout至180，并同步加大net_read_timeout和net_write_timeout到120 - 关闭
slave_compressed_protocol = OFF（5.7+默认ON），压缩反而增加CPU等待，对高延迟链路得不偿失 - 启用
slave_parallel_workers = 4但限制slave_parallel_type = LOGICAL_CLOCK，避免多线程争抢同一张表造成死锁回滚
网络抖动是常态，不是异常。真正要盯的不是平均延迟，而是延迟毛刺是否触发了超时阈值——那才是同步断裂的起点。
