跨机房MySQL远程同步需以GTID+半同步复制为基础，辅以Canal/Kafka等CDC中间件解耦缓冲，并通过应用双写+定期校验兜底，同时调优网络参数与权限策略。
跨机房 MySQL 远程同步，核心是解决网络延迟、带宽限制、数据一致性与故障容错问题。不能只靠原生主从复制硬扛，需结合架构设计、中间件和运维策略来保障稳定性与可用性。
用 GTID + 半同步复制打基础
传统基于 binlog file/pos 的复制在跨机房场景下极易因网络抖动导致位置错乱或中断重试失败。GTID（Global Transaction Identifier）让每个事务有全局唯一标识，主从切换、断点续传更可靠。配合半同步（semi-sync），确保至少一个从库写入 relay log 后主库才返回成功，避免脑裂和数据丢失。
- 主库开启 gtid_mode=ON、enforce_gtid_consistency=ON
- 从库配置 master_auto_position=1，自动按 GTID 拉取
- 部署 rpl_semi_sync_master 和 rpl_semi_sync_slave 插件，超时设为 5～10 秒（太短易退化为异步，太长影响业务）
加一层复制中间件做缓冲与路由
直接主从跨公网或长距离专线，一卡全卡。引入 Canal / Maxwell / Debezium 等 CDC 工具，把 MySQL 的 binlog 解析成标准消息（如 JSON 或 Protobuf），投递到 Kafka 或 Pulsar。下游消费端再写入目标机房的 MySQL，实现解耦、限流、重试、顺序保障。
- Canal 部署在源库所在机房，降低对主库压力；Kafka 跨机房部署多副本，保证消息不丢
- 消费程序需支持幂等写入（如先查后插、replace into、on duplicate key update）
- 可按库表分 topic 或分区，保证同一张表变更顺序消费
双写+校验兜底，避免单点失效
即使有强同步链路，仍建议关键业务走“应用双写 + 定期比对”模式：业务层同时写本地库和远程库（异步或降级开关可控），再通过定期 checksum（如 pt-table-checksum）或行级快照比对工具发现差异，并触发修复流程。
- 双写不强依赖网络，失败可落本地消息队列重试
- 每日凌晨跑一次全量校验，增量校验可每小时一次，重点监控大表和热点表
- 修复脚本应支持按主键生成 replace 语句，避免误删或覆盖
网络与权限必须提前调优
跨机房不是“能连上就行”。MySQL 默认超时、包大小、重试机制都不适合广域网环境。
