MySQL主从跨机房同步频繁中断主因是默认超时参数过小（slave_net_timeout=60s，net_read/write_timeout=30s），高延迟网络下易触发IO线程断连；需调大超时值、启用GTID多线程复制、配置relay log本地缓存并严格校验数据一致性。
MySQL主从复制在高延迟网络下为什么频繁中断
跨机房同步本质是主从复制，但延迟高（比如 200ms+）时，CHANGE MASTER TO 配置里没调参，slave_net_timeout 默认 60 秒，加上 net_read_timeout 和 net_write_timeout 默认 30 秒，主库稍一卡顿或网络抖动，IO 线程就直接报 ERROR 2013 (HY000): Lost connection to MySQL server during query 并断开重连，形成恶性循环。
实操建议：
- 把
slave_net_timeout设为 120～300（单位秒），必须大于 RTT 的 3 倍；同时调大net_read_timeout和net_write_timeout至 180+ - 主库侧开启
sync_binlog = 1和innodb_flush_log_at_trx_commit = 1是安全前提，但会牺牲写入吞吐——跨机房场景下别为了“性能”关掉它们 - 避免用
mysqlbinlog --read-from-remote-server手动拉日志，它不带重试和断点续传，一丢包就全崩
用 GTID + 多线程复制降低延迟累积
传统基于 position 的复制在跨机房容易因单 SQL 阻塞（如大事务、DDL）导致整个 SQL 线程卡住，延迟越积越大。GTID 能自动定位同步位点，配合 slave_parallel_type = LOGICAL_CLOCK 和 slave_parallel_workers = 4～8，让不同 database 或事务组并行回放，显著缓解延迟毛刺。
注意几个硬约束：
- 主从都必须开启
gtid_mode = ON且enforce_gtid_consistency = ON，否则START SLAVE会报错ERROR 1777 (HY000): Setting @@GLOBAL.GTID_MODE is not allowed - 不能有非事务引擎表（如 MyISAM），否则 GTID 无法生成，复制直接失败
-
slave_preserve_commit_order = ON必须打开，否则并行回放可能破坏事务先后顺序，导致从库数据逻辑错乱
用 relay log 本地缓存扛网络抖动
网络不稳定时，IO 线程拉日志失败是常态。靠默认的 relay log 机制不够，因为 relay_log_space_limit 默认为 0（不限制），磁盘写满或 IO 线程反复重建 relay log 文件会导致位置丢失。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
稳妥做法：
- 显式配置
relay_log = /data/mysql/relay-bin和relay_log_index = /data/mysql/relay-bin.index，避免依赖默认命名规则 - 设
relay_log_space_limit = 4G（根据日均 binlog 量定），配合relay_log_purge = ON，防止磁盘爆满 - 加一层监控：定期查
SHOW SLAVE STATUS\G中的Seconds_Behind_Master和Relay_Log_Space，一旦后者接近 limit 值，说明网络持续异常，需人工介入
跳过错误 or 修复数据？别盲目用 SET GLOBAL sql_slave_skip_counter
遇到 duplicate entry 或 no such table 就执行跳过，等于埋雷。跨机房同步中，这类错误往往意味着主从元数据已不一致（比如从库少建了一张表），或者主库 binlog 被截断、relay log 损坏。
更安全的路径是：
- 先停复制：
STOP SLAVE，再查SHOW SLAVE STATUS\G确认Exec_Master_Log_Pos和Relay_Master_Log_File，记下出问题的 binlog 位置 - 用
mysqlbinlog解析对应 binlog 文件，确认那条语句是否真的可跳（比如只是 insert 主键冲突，且业务允许忽略） - 真要跳，优先用
SET GTID_NEXT='xxx'; BEGIN; COMMIT;注入空事务（GTID 模式下），比sql_slave_skip_counter更可控 - 所有跳过操作必须记录工单，并在 24 小时内做一次主从
mysqldump --single-transaction --master-data=2全量校验
真正难的不是配置参数，是判断哪次延迟是毛刺、哪次是数据已裂开。网络抖动可以等，数据不一致只能重搭。
