MySQL跨机房同步频繁中断主因是默认超时参数过小（slave_net_timeout=60s，net_read/write_timeout=30s），高延迟网络下易触发IO线程断连；需调大超时值、启用GTID多线程复制、配置relay log本地缓存并严格校验数据一致性。
跨机房 MySQL 容灾架构中，网络抖动不是“偶尔卡一下”的小问题，而是会直接触发 ERROR 2013 (HY000): Lost connection to MySQL server during query、让 Seconds_Behind_Master 失真甚至恒为 0 的系统性风险——根源在于 MySQL 复制线程对 TCP 层异常极其敏感，而默认参数完全没考虑 20–80ms RTT 和 0.1%–1% 丢包率的现实。
为什么 slave_net_timeout 必须调大，且不能只改从库
MySQL 从库靠 slave_net_timeout 判断主库是否失联：它指“收不到任何数据的空闲等待时长”，不是心跳间隔。默认值 3600 秒在同机房够用，但在跨机房，一次 200ms 抖动 + 主库短暂 GC 就可能突破旧版（如 5.6）的 60 秒隐式限制，导致 IO 线程反复断连重试。
- 生产建议设为
120～300（单位秒），必须 > 实测 RTT 的 3 倍（例如 RTT 波动在 40±15ms，就至少设 180） - 该参数是全局动态变量，但 MySQL 5.6 及更早版本不支持运行时修改，必须写入
my.cnf并重启mysqld - 修改后需手动重启 IO 线程：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;，否则不生效 - 主库也要同步调大
net_read_timeout和net_write_timeout至180，否则 dump 线程在发大事务 binlog 时可能先被主库主动断开
如何用 MASTER_HEARTBEAT_PERIOD 避免假断连
MySQL 5.7+ 引入了真正的复制心跳机制，但它由主库主动推送 HEARTBEAT event，和 slave_net_timeout 是两套逻辑。不配这个，从库只能等超时才感知“主库活着但没新日志”，中间窗口期全靠猜。
- 主库执行：
CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 15;（单位秒，建议 ≤slave_net_timeout- 10） - 必须在复制运行中执行，且执行后要重启从库的 IO 线程才能生效
- 心跳 event 不写入 relay log，也不参与 GTID 计数，纯属连接保活；若主库
binlog_format = STATEMENT，某些场景下可能被跳过，统一用ROW更稳 - 搭配系统级
tcp_keepalive参数：在主从两端同时设net.ipv4.tcp_keepalive_time = 600、net.ipv4.tcp_keepalive_intvl = 60、net.ipv4.tcp_keepalive_probes = 3，防中间防火墙/NAT 清连接
为什么 slave_compressed_protocol = 1 是性价比最高的第一优化
跨机房复制流量 ≈ 主库 binlog 写入量，而 ROW 格式下一条 UPDATE 可能带几 KB 原始数据。不压缩就是裸奔传明文，带宽打满、TCP 重传飙升、延迟毛刺放大——启用压缩不改架构、不升级硬件、不增加运维复杂度，却能直接压降 30%–50% 网络负载。
- 仅需在从库
my.cnf中加一行：slave_compressed_protocol = 1，然后SET GLOBAL slave_compressed_protocol = 1或重启生效 - 无需主库配合，不依赖 binlog 格式或 GTID，MySQL 5.7.9+ 原生支持
- 轻微增加从库 CPU（通常
- 注意：如果从库已启用了
zstd压缩（MySQL 8.0.20+），优先用它替代默认 zlib，压缩率更高
哪些“看起来合理”的操作反而会让抖动更致命
很多调参动作本意是提速，但在高抖动链路上会放大风险，比如盲目调大并行 worker 数、关掉 semi-sync、或依赖 Seconds_Behind_Master 做自动切换。
- 别一见延迟就加
slave_parallel_workers：若主库未开启binlog_group_commit_sync_delay或事务组太小，并行线程会因争抢 relay log 文件锁而内耗，反而比单线程还慢 - 别禁用
rpl_semi_sync_master_enabled：异步复制下，主库 crash 后未同步的 binlog 永久丢失；semi-sync 超时退化是常态，关键要把rpl_semi_sync_master_timeout设为1000000（1 秒），并确保从库slave_net_timeout ≥ 2 -
Seconds_Behind_Master在抖动恢复后常短暂飙高，但这不等于 SQL 线程卡住——真正要看Slave_IO_Running和Slave_SQL_Running是否均为Yes，以及Retrieved_Gtid_Set和Executed_Gtid_Set差值 - 监控脚本里不能只告警
Seconds_Behind_Master > 60，必须前置校验两个线程状态，否则抖动期间会狂发误告
网络抖动无法根除，但可以把它从“故障触发器”变成“可预期背景噪声”。最易忽略的是：所有这些优化都必须在主从两端同步实施，尤其是 TCP 内核参数和 keepalive 设置——单边调整等于白做。
