多源复制是多个独立复制通道协同工作的机制，每个通道（for channel 'xxx'）拥有独立io线程、sql线程、中继日志及位点记录，不共享状态；必须配置master_info_repository和relay_log_info_repository为table，通道名需唯一合法，启动须显式指定for channel，且需主动规避库表冲突。
多源复制不是“开启一个开关”，而是靠多个独立复制通道协同工作的机制；理解它，关键不是背定义，而是看清每个通道如何隔离、如何注册、如何运行。
多源复制本质是多个独立的 Slave 实例共存于一台从库
每个 FOR CHANNEL 'xxx' 定义的是一套完整的复制单元：有自己的 IO_THREAD、SQL_THREAD、中继日志文件、位点记录位置。它和默认通道（空名）完全不共享状态，也不会互相干扰。
常见误解是以为“加个参数就能多主同步”，实际只要漏掉 FOR CHANNEL，语句就会落到默认通道上，后一次覆盖前一次，且不报错——看起来配置了两个源，其实只跑了一个。
- 每个通道必须有唯一、合法的通道名：只允许字母、数字、下划线，不能含点、短横、空格
- 通道名建议带业务含义，比如
'order_master'、'user_master'，避免用'a'、'1'这类简写，否则SHOW REPLICA STATUS FOR CHANNEL查状态时极易混淆 - 没有“全局启动”这回事：
START REPLICA不带FOR CHANNEL只启默认通道；其他通道必须显式执行START REPLICA FOR CHANNEL 'xxx'
master_info_repository 和 relay_log_info_repository 必须为 TABLE
这是硬性前提，不是可选项。FILE 模式下执行任何带 FOR CHANNEL 的 CHANGE REPLICATION SOURCE TO 都会立刻报错：ERROR 3077 (HY000): To have multiple channels, repository cannot be of type FILE。
动态修改需先停所有复制线程：STOP REPLICA（注意：5.7.28+ 已弃用 STOP SLAVE），再设变量：
SET GLOBAL master_info_repository = 'TABLE'; SET GLOBAL relay_log_info_repository = 'TABLE';
改完必须确认：
SHOW VARIABLES LIKE '%repository%';
两个值都应为 TABLE。哪怕你只新增第二个通道，只要任一仍是 FILE，新通道就无法注册成功——失败是静默的，SHOW REPLICA STATUS 根本不显示它。
通道之间不自动隔离库表，冲突靠 DBA 主动规避
MySQL 不做跨通道的库名/表名冲突检查。如果两个主库都有 orders 库，又没配置 replicate-rewrite-db，它们会直接在从库上撞在一起，造成数据覆盖或 DDL 失败。
典型应对方式：
- 用
replicate-rewrite-db=src_db->dst_db重命名目标库名，比如replicate-rewrite-db=order_v1->order_master - 确保各主库的
server-id全局唯一，避免 GTID 冲突（若启用 GTID） - 各通道的
relay-log文件前缀必须不同，例如relay-log = /var/lib/mysql/relay_order和relay-log = /var/lib/mysql/relay_user，否则中继日志会互相覆盖
真正容易被忽略的是：通道名拼写错误、relay-log 前缀重复、以及误以为 START REPLICA 能批量启动所有通道——这三个点几乎覆盖了生产环境中 80% 的“配置完了但没同步”问题。
