跨机房迁移MySQL核心是“先同步、再切换”，需保障数据一致性、最小化中断、应对网络延迟与故障；须结合主从复制等机制，优先选用基于GTID的主从复制，要求网络稳定且延迟可控。
跨机房迁移 MySQL 的核心是“先同步、再切换”，关键在于保障数据一致性、最小化业务中断、应对网络延迟与故障。不能只靠 mysqldump 全量导出导入，必须结合主从复制或更稳定的同步机制。
基于 GTID 的主从复制（推荐首选）
适用于两个机房网络稳定、延迟可控（建议
- 在源库开启 gtid_mode=ON、enforce_gtid_consistency=ON，确保所有写操作兼容 GTID
- 用 mysqldump –set-gtid-purged=ON 导出全量，并在目标库导入（保留原始 GTID 信息）
- 导入完成后，在目标库执行 CHANGE MASTER TO … GET_MASTER_PUBLIC_KEY=1，指向源库主节点，使用 START SLAVE
- 通过 SHOW SLAVE STATUS/G 检查 Seconds_Behind_Master 和 Retrieved_Gtid_Set == Executed_Gtid_Set 判断是否追平
使用 Canal + 消息队列（适合高可用与异构场景）
当跨机房网络抖动频繁、需解耦或后续要对接 Kafka/ES 等系统时，Canal 是成熟选择。它伪装成从库拉取 binlog，解析后投递到消息中间件，由下游消费写入目标 MySQL。
- 在源库开启 binlog（log-bin=ON、binlog_format=ROW、server_id 唯一）
- 部署 Canal Server，配置 instance 指向源库；搭配 Kafka 或 RocketMQ 存储变更事件
- 开发或选用现成的 sink 组件（如 canal-client、otter、sharding-jdbc-sink），按事务顺序写入目标库，注意幂等与冲突处理（如主键重复跳过或覆盖）
- 全量数据可单独用 DataX 或 mydumper 并行导入，再通过 Canal 补增量，实现平滑过渡
双写 + 校验 + 切流（低风险兜底方案）
对一致性要求极高、无法接受任何丢失或延迟的业务（如金融类），可在应用层改造为同时写两个库，再通过工具校验+修复，最后灰度切流量。
- 应用接入双写中间件（如自研代理、ShardingSphere-Proxy 分片路由双写），写请求发往新老库（注意事务边界，建议最终一致性）
- 使用 pt-table-checksum 定期比对主从表级数据一致性，配合 pt-table-sync 修复差异
- 切流前冻结写入，等待双库完全一致后，逐步将读流量、再写流量切至新机房，旧库降级为只读备库
- 全程保留回滚能力：DNS 或负载均衡快速切回，旧库保留至少 72 小时
注意事项与避坑点
跨机房不是单纯技术问题，更是运维协同过程。以下细节常被忽略但直接影响成败：
- 时间同步必须统一：两机房服务器务必 NTP 对齐，否则 GTID 复制、binlog 解析、日志排查都会混乱
- 防火墙与白名单：确认源库 3306（或自定义端口）、Canal Server 所需端口、Kafka 端口双向可达，禁止仅开单向
- 大表 DDL 要规避：迁移期间禁止在源库执行 ALTER TABLE 等阻塞操作，否则从库可能卡住甚至复制中断
- 监控不可少：除了 Seconds_Behind_Master，还需监控网络丢包率、Canal 消费延迟、目标库 QPS/慢查询/连接数，设置告警阈值