跨云部署MySQL 5.7双主热备不可行，须改用GTID+主从+故障切换方案；因网络延迟高、丢包多导致复制卡顿或中断，且双主无法处理写冲突，auto-increment-offset在跨云下亦失效。
跨云部署 MySQL 5.7 双主热备不可行，必须放弃“双主”思路，改用 GTID + 主从 + 故障切换方案。 原因很直接：跨云网络延迟高、丢包不可控、TCP 连接频繁中断，CHANGE MASTER TO ... MASTER_AUTO_POSITION=1 在这种环境下极易卡在 Waiting for master to send event 或反复重连失败；更关键的是，MySQL 原生双主（互为主从）不处理写冲突，一旦两边同时写同一张表的自增主键或唯一键，立刻报 Duplicate entry 或复制中断，且无法自动修复。
为什么 auto-increment-offset 不适合跨云双主
本地 IDC 或同机房双主靠 auto-increment-increment=2 + auto-increment-offset=1/2 避免主键冲突，前提是网络稳定、时钟一致、无脑裂。但跨云场景下：
• 云厂商之间 BGP 路由抖动常见，SHOW SLAVE STATUS\G 中的 Seconds_Behind_Master 经常跳变甚至负值；
• 任一节点短暂失联后恢复，IO_THREAD 可能拉取到旧 binlog position，导致自增 ID 重复插入；
• 没有全局时钟同步机制，server-id 冲突检测形同虚设；
• replicate_do_db 等过滤规则在跨云长连接下极易漏同步或错同步。
GTID 模式下跨云主从的实际配置要点
若坚持用 MySQL 自带复制能力实现跨云容灾，必须只走单向主从（非双主），并严格启用 GTID：
• 主库（云 A）和从库（云 B）均开启：gtid_mode=ON、enforce_gtid_consistency=ON、master_info_repository=TABLE、relay_log_info_repository=TABLE；
• 主库 log_bin 和从库 log_slave_updates=ON 必须开启（跨云从库要能继续当主库用）；
• 从库连接命令必须用 MASTER_AUTO_POSITION=1，禁用 MASTER_LOG_FILE/MASTER_LOG_POS 手动定位；
• 设置超时参数防假死：MASTER_CONNECT_RETRY=10、MASTER_RETRY_COUNT=86400、MASTER_HEARTBEAT_PERIOD=15.0；
• 从库务必加 read_only=ON（但允许 super 用户写），避免误操作污染 GTID 集合。
真正可用的跨云 MySQL 高可用替代方案
生产环境应绕开 MySQL 原生复制的局限：
• PXC（Percona XtraDB Cluster）不适用跨云：其同步是强一致性（quorum 投票），跨云网络延迟 >50ms 就会导致集群频繁分裂，wsrep_local_state_comment: Joiner 卡死；
• 推荐用中间件层切流 + 异步双写：应用层通过 ShardingSphere 或 MyCat 实现写请求路由到主云，读请求按权重分发；主云写完后，通过 Kafka + Canal 解析 binlog 推送到云 B 的消费服务做最终一致性写入；
• 云厂商 RDS 服务更稳妥：阿里云 DTS、腾讯云 DTS、AWS DMS 均支持跨地域 binlog 解析+断点续传+冲突过滤（如忽略 Duplicate entry、跳过 DDL），比自己搭更可靠；
• 若必须自建，只保留一个可写主库，另一云节点仅作为只读从库+备份目标，故障时人工 STOP SLAVE; RESET MASTER; 后提升，不追求“自动双主”。
跨云 MySQL 架构里最易被忽略的一点：不要信任 Seconds_Behind_Master 数值。它在跨云链路中经常不准，真实延迟要看 relay_log_space 增长速度和 Retrieved_Gtid_Set 与 Executed_Gtid_Set 的差集大小。监控必须基于 GTID 集合比对，而不是时间戳。
