跨数据中心MySQL主从复制需调优网络与GTID参数：设slave_net_timeout=60、启用slave_compressed_protocol、禁用skip_slave_start并加重启逻辑；GTID场景须避免gtid_purged误设，慎用enforce_gtid_consistency；半同步在跨城下易退化，建议改用MASTER_DELAY；禁用库表级复制过滤，优先应用层写分离。
主从复制跨数据中心时的网络延迟应对策略
跨数据中心复制最直接的问题不是配置失败，而是 Seconds_Behind_Master 持续飙升甚至卡死。这不是 MySQL 配置错了，而是 TCP 层在高延迟（比如 50–200ms RTT）下默认参数严重不适应。
- 必须调大
slave_net_timeout（建议设为60），否则从库在短暂网络抖动后会主动断开 IO 线程，反复重连导致复制中断 - 在从库的
my.cnf中启用slave_compressed_protocol=ON，能显著降低带宽占用和传输时间，尤其对大事务日志有效 - 禁用
skip_slave_start，但要在启动脚本里加重试逻辑——因为跨 DC 的首次连接失败率高，靠 MySQL 自身不重试
如何避免跨数据中心复制中的 GTID 冲突与切换失效
开启 GTID 后跨 DC 复制，常见现象是主库 failover 后从库报错 Could not execute Write_rows_v1 event on table xxx; Duplicate entry，本质是 GTID set 不一致或 gtid_purged 被错误覆盖。
- 主库执行
RESET MASTER前，必须先在所有从库上记录当前SELECT @@global.gtid_executed;，否则重建主库后无法安全指向新位点 - 从库不要手动执行
SET GLOBAL gtid_purged = '...';，除非你已停掉 SQL 线程、清空 relay log 并确认该 GTID 集合完全不包含本地已执行事务 - 跨 DC 场景下，建议关闭
enforce_gtid_consistency = OFF（仅限明确不使用匿名事务的环境），避免因存储过程/临时表等触发强制拒绝
半同步复制在跨数据中心下的实际效果与取舍
rpl_semi_sync_master_enabled=ON 在同城双机房可能有效，但在跨城（如北京 ↔ 广州）基本不可用：只要一个 ACK 超时（默认 rpl_semi_sync_master_timeout=10000 ms），就会自动退化为异步，且后续不会自动恢复半同步状态。
- 若坚持用半同步，必须把
rpl_semi_sync_master_timeout设为 ≥ 30000，并配合监控Rpl_semi_sync_master_status和Rpl_semi_sync_master_no_tx指标，及时发现退化 - 更稳妥的做法是关闭半同步，改用
MASTER_DELAY（如CHANGE MASTER TO MASTER_DELAY = 3600），牺牲实时性换回可控性——延迟复制至少能防误删、误更新 - 注意：延迟复制不兼容
LOG_BIN_TRUST_FUNCTION_CREATORS等依赖精确时序的审计方案
复制过滤规则在跨数据中心链路中的风险点
用 replicate_do_db 或 replicate_wild_do_table 做库表级过滤，看似节省带宽，实则在跨 DC 场景中极易引发数据不一致。
- 基于库的过滤（
replicate_do_db）受USE db_name影响，而主库上的跨库操作（如INSERT INTO otherdb.t1 SELECT * FROM mydb.t2）会被从库忽略，造成静默丢失 - 推荐只用
replicate_rewrite_db做命名空间映射（如把主库prod_xxx映射到从库dr_xxx），并确保所有 DML 显式指定库名 - 真正需要过滤时，优先在应用层做写分离，而不是依赖从库复制过滤——后者一旦配置出错，恢复成本极高
CHANGE MASTER TO MASTER_HOST='10.20.30.40', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_SSL=1, MASTER_SSL_CA='/etc/mysql/ca.pem', MASTER_SSL_CERT='/etc/mysql/client-cert.pem', MASTER_SSL_KEY='/etc/mysql/client-key.pem', MASTER_AUTO_POSITION=1, MASTER_DELAY=3600;
跨 DC 复制没有“开箱即用”的最优解，关键参数往往要根据真实 RTT、事务大小分布、failover 频率反复调。最容易被忽略的是：从库磁盘 I/O 能力必须 ≥ 主库，否则网络再快，relay log 写不过来照样堆积。
