mysql 8.0多源复制不自动保障灾备库数据一致性，必须依赖gtid、唯一server_uuid、log_slave_updates=on及业务层分表/写路由等架构设计共同实现；漏配for channel或主键冲突将导致sql线程停止。
MySQL 8.0 多源复制本身不自动保障灾备库数据一致性；必须靠架构设计+GTID+冲突规避策略共同实现，否则极易出现主键冲突、丢失更新或应用中断。
多源复制的通道配置必须用 FOR CHANNEL 显式声明
每个主库必须绑定独立通道名，不能复用默认通道。否则后续 START SLAVE 或状态查询会混淆来源：
-
CHANGE MASTER TO必须带FOR CHANNEL 'chan_a'，例如：CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1 FOR CHANNEL 'chan_a'; - 同理为第二个主库配置
FOR CHANNEL 'chan_b'，通道名需全小写、无特殊字符、长度 ≤ 64 - 漏写
FOR CHANNEL会导致该配置被写入默认通道（空字符串），后续SHOW SLAVE STATUS查不到对应条目，START SLAVE FOR CHANNEL会报错Unknown channel - MySQL 8.0 不允许同一实例中两个通道指向相同
server_id的主库，否则启动时直接拒绝
GTID 是多源一致性的底线，禁用 log_slave_updates 会断链
启用 gtid_mode=ON 和 enforce_gtid_consistency=ON 是强制要求。但仅此不够——若灾备库本身还要作为其他节点的主库（如级联场景），必须开启 log_slave_updates=ON：
- 关闭
log_slave_updates时，从各通道收到的事务不会写入本机 binlog，导致下游无法继续复制，灾备链路断裂 - 开启后，所有通道应用的事务都会生成本地 GTID 并记入 binlog，但要注意：不同主库可能产生相同 GTID（如都用
uuid:1），此时 MySQL 8.0 会拒绝启动，必须确保各主库的server_uuid全局唯一（安装时自动生成，不可手动覆盖） - 验证方式：
SELECT * FROM performance_schema.replication_connection_status\G中检查CHANNEL_NAME和GROUP_REPLICATION_GROUP_NAME字段是否为空，非空说明 GTID 正常识别
避免写冲突的核心是禁止多源同时写同一张表
MySQL 不提供跨通道的冲突检测或自动合并机制。一旦两个主库向灾备库同步同一张表（如 orders），且发生主键/唯一键重复，SQL 线程立即停止，Seconds_Behind_Master 变为 NULL，错误日志里出现 Duplicate entry '123' for key 'PRIMARY'：
- 推荐做法：按业务域分表，例如
orders_shard_a来自主库 A，orders_shard_b来自主库 B，灾备库上用视图或应用层 union - 若必须合表，应在主库侧做写路由（如中间件分片），或在灾备库上用
replicate_rewrite_db重写库名，再通过触发器/存储过程做字段映射和去重 - 禁用
auto_increment_increment/auto_increment_offset—— 这是双主场景用的，多源下无效，反而干扰 GTID 事务顺序 - 监控关键指标：
SHOW SLAVE STATUS FOR CHANNEL 'chan_a'\G中的Retrieved_Gtid_Set和Executed_Gtid_Set应持续增长且差值稳定（延迟小），若某通道的Executed_Gtid_Set停滞，大概率已卡在冲突上
真正难处理的不是配置步骤，而是当多个主库时间线交错、事务交叉提交时，灾备库上 SQL 线程只能串行回放——这意味着即使开了并行复制（slave_parallel_workers > 0），不同通道之间仍完全隔离，无法跨通道并行。这点常被忽略，结果灾备延迟远超预期。
