跨云MySQL迁移需确保网络通、协议稳、数据准：优先公网白名单打通网络，禁用GTID用原生主从同步，通过FLUSH LOGS获取准确binlog位点，避免因网络抖动或配置错误导致静默中断。
跨云 MySQL 迁移，本质是网络通 + 协议稳 + 数据准
跨云迁移不是换台服务器那么简单。云厂商的 VPC 默认隔离，MySQL 的 binlog 同步依赖稳定长连接，而公有云之间往往没有直连通道。直接用 mysqldump 导出再导入，只适合一次性小库；真要持续同步或低中断切换，必须先打通网络层，再选对复制机制。
网络打通：优先走公网白名单，别硬搞 VPC 对等连接
阿里云和腾讯云之间、AWS 和华为云之间，官方 VPC 对等连接基本不支持。强行配 NAT 网关 + 安全组放行，延迟高、丢包多，CHANGE MASTER TO 极易报错 ERROR 2013 (HY000): Lost connection to MySQL server during query。
- 最稳妥做法：在源库所在云上，给目标库的公网 IP 加一条安全组规则，仅开放
3306端口（别开0.0.0.0/0） - 目标库必须开启
bind_address = 0.0.0.0，且用户授权带GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY 'xxx'; - 若源库无固定公网 IP，用云厂商的弹性公网 IP（EIP）绑定，避免因 NAT 映射变化导致主从断连
数据同步：用原生主从最省心，mysqldump + mysqlbinlog 补差
第三方工具如 canal 或 Debezium 在跨云场景下配置复杂、版本兼容性差，容易卡在 connect timeout 或 Unknown system variable 'binlog_checksum' 上。原生基于 binlog 的主从复制，协议简单、MySQL 版本兼容性好，只要网络通，就大概率能跑起来。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 源库确认已开启
log_bin = ON、server_id = 1，并执行FLUSH LOGS;获取最新 binlog 文件名和位置 - 目标库执行
CHANGE MASTER TO MASTER_HOST='xxx.xxx.xxx.xxx', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;—— 注意MASTER_LOG_POS必须和SHOW MASTER STATUS;输出一致，否则同步会跳过部分事务 - 如果中间有延迟或断连，用
mysqlbinlog --read-from-remote-server抓取缺失的 binlog 补到目标库，比重做全量快得多
常见坑：GTID 模式在跨云主从里容易失效
很多团队默认开启 gtid_mode = ON，但在跨云环境，GTID_EXECUTED 集合可能因网络抖动或重启丢失一部分，导致 START SLAVE 报 Could not execute Write_rows event on table xxx; Duplicate entry 'xxx' for key 'PRIMARY'。
- 迁移初期建议关掉 GTID：
gtid_mode = OFF、enforce_gtid_consistency = OFF，等同步稳定后再评估是否启用 - 若必须用 GTID，务必在
CHANGE MASTER TO后加MASTER_AUTO_POSITION = 1，且确保源库没执行过RESET MASTER -
SHOW SLAVE STATUS\G中重点关注Seconds_Behind_Master和Retrieved_Gtid_Set是否持续增长，不增长说明 IO 线程根本没拉到日志
真正难的从来不是命令怎么写，而是哪条网络策略漏了、哪个 binlog 位点记错了、哪次 FLUSH LOGS 没刷成功——这些细节一错，同步就静默卡住，查日志还全是“OK”。
