MySQL 8.0+ 多源复制必须用 CHANGE REPLICATION SOURCE TO，通道名需语义清晰且唯一；须停复制后配置，SOURCE_HOST需DNS可达；需统一auto_increment配置并设从库表为READ ONLY；禁用并行复制以防阻塞；确保relay_log_purge=ON防磁盘占满；注意各主库binlog_format一致。
MySQL 8.0+ 多源复制必须用 CHANGE REPLICATION SOURCE TO
MySQL 5.7 起废弃了 CHANGE MASTER TO，8.0+ 完全移除。多源复制依赖多个独立的复制通道（channel），每个通道对应一个主库，必须显式命名。不指定 SOURCE_CONNECTION_AUTO_FAILOVER=1 时，通道名就是唯一标识，写错或重复会导致 ERROR 3077 (HY000)。
实操建议：
- 每个通道名用清晰语义，比如
chan_us_east、chan_sg，避免用数字或master1这类易混淆命名 - 建通道前先停掉所有复制：
STOP REPLICA;，否则可能因并发修改报ERROR 3080 - 执行
CHANGE REPLICATION SOURCE TO时，SOURCE_HOST必须可被从库 DNS 解析，不能填localhost或未绑定的内网 IP（常见于 Docker 网络）
多主一从的冲突风险不在 SQL 层，而在 GTID 和 auto-increment
多源复制本身不校验数据逻辑一致性。真正出问题的场景是：两个主库同时插入同一张表，且都用 AUTO_INCREMENT。即使设置了 auto_increment_offset 和 auto_increment_increment，只要从库自身也写入过该表（比如临时修复脚本），自增计数器就可能错乱，导致 Duplicate entry 'X' for key 'PRIMARY'。
实操建议：
- 所有上游主库的
auto_increment_increment设为相同值（如 10），auto_increment_offset各不相同（如 1, 2, 3…），并确保从库该表设为READ ONLY - 禁用从库的 GTID 自动执行（
replica_gtid_policy = OFF），改用SET GLOBAL gtid_next = 'ANONYMOUS'手动跳过冲突事务——但仅限紧急修复，不可长期开启 - 定期检查
SHOW REPLICA STATUS FOR CHANNEL 'xxx'中的Seconds_Behind_Source和Retrieved_Gtid_Set，发现某通道 GTID 落后或跳跃，大概率已丢事务
replica_parallel_workers > 0 在多源下反而容易卡住
启用并行复制（replica_parallel_workers = 4）本意是提速，但在多源场景中，MySQL 会为每个通道单独维护 worker 队列。一旦某个通道持续延迟（比如网络抖动、大事务未提交），其他通道的 worker 可能被阻塞等待全局协调点，表现为所有通道 Seconds_Behind_Source 突然飙升，但 CPU 和 IO 并不高。
实操建议：
- 多源环境下优先关掉并行复制：
SET GLOBAL replica_parallel_workers = 0;，靠单线程保顺序和稳定 - 若必须并行，只对高吞吐、低事务冲突的通道开启（如日志归集库），并设置
replica_preserve_commit_order = ON防止跨通道提交乱序 - 监控
performance_schema.replication_applier_status_by_coordinator表，重点关注APPLYING_EVENT状态是否长时间卡在某个 channel
从库磁盘空间暴增往往是因为 relay log 没自动清理
多源复制默认为每个通道创建独立 relay log 文件（如 relay-bin-us-east.000001），但 relay_log_purge 是全局开关，一旦设为 OFF（某些备份工具会临时关闭），所有通道的 relay log 都不会被清理，几天就能吃光磁盘。错误日志里看不到明显报错，只会在 SHOW PROCESSLIST 里看到大量 Waiting for master to send event 状态。
实操建议：
- 确认
relay_log_purge = ON（默认值），并检查relay_log_space_limit是否设得过大（如 0 表示无上限） - 手动清理前先停对应通道：
STOP REPLICA FOR CHANNEL 'xxx';，再执行PURGE RELAY LOGS BEFORE 'relay-bin-xxx.000010'; - 把
SELECT * FROM performance_schema.replication_applier_status_by_worker;加进巡检脚本，关注LAST_SEEN_TRANSACTION是否长时间没更新
多源复制不是“配好就完事”的功能，每个通道都是独立故障面。最常被忽略的是：不同主库的 binlog_format 不一致（比如 MIXED 和 ROW 混用），会导致从库解析失败却静默跳过，数据差异肉眼不可见。
