mysql多源复制不强制要求gtid模式，但强烈建议启用；必须为每个主库配置独立命名通道；库名冲突需主库改名或从库重写；show slave status默认仅显示默认通道，须用for channel或查询performance_schema表。
MySQL 多源复制必须用 GTID 模式吗？
不是必须，但强烈建议开启。MySQL 5.7+ 支持基于 binlog position 和 GTID 两种多源复制模式，但 position 模式在多个主库存在同名数据库、表结构不一致、或某主库重启后 binlog 被轮转时极易出错——START SLAVE 会因找不到指定 MASTER_LOG_FILE 或 MASTER_LOG_POS 直接失败。GTID 模式靠事务唯一标识自动定位，容错性高得多，且 CHANGE REPLICATION SOURCE TO（8.0.23+）或 CHANGE MASTER TO（5.7–8.0.22）中设置 SOURCE_AUTO_POSITION = 1 后无需手动管理位点。
如何为每个主库单独配置复制通道？
每个主库必须绑定独立的复制通道（channel），否则 IO 线程冲突，SHOW SLAVE STATUS 只显示默认通道（空名），其余通道状态需显式指定。实操要点：
- 创建前先停掉所有复制：
STOP SLAVE（非STOP SLAVE FOR CHANNEL ''，它只停默认通道） - 为每个主库用
FOR CHANNEL 'xxx'显式命名通道，例如：CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.1.10', SOURCE_USER='repl', SOURCE_PASSWORD='pwd1', SOURCE_PORT=3306, SOURCE_AUTO_POSITION=1 FOR CHANNEL 'master_a';
- 启动时也必须带通道名：
START SLAVE FOR CHANNEL 'master_a'，否则只启默认通道 - 通道名区分大小写，且不能含空格或特殊字符，推荐全小写 + 下划线
从库上数据库名冲突怎么处理？
多源复制不支持自动重映射库名，若两个主库都有 orders 库，直接同步会导致 DDL/DML 冲突。解决方式只有两种：
- 主库侧改名：在各主库上用
RENAME DATABASE（已废弃）或更稳妥地导出 + 修改库名 + 导入，确保各主库同步的库名全局唯一 - 从库侧过滤 + 重写：启用
replicate_rewrite_db（5.7）或REPLICATE_REWRITE_DB（8.0，需在CHANGE REPLICATION SOURCE TO中设置），例如：CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.1.11', ... REPLICATE_REWRITE_DB=('sales', 'sales_b')注意该参数仅对库级语句生效，不重写表名；且 8.0.23+ 已移除，改用replication_applier_configuration表配合规则引擎
为什么 SHOW SLAVE STATUS 看不到所有通道？
这是最常被忽略的点：SHOW SLAVE STATUS 默认只返回空字符串通道（即默认通道）的状态。要查全部，必须用 SHOW SLAVE STATUS FOR CHANNEL 'xxx' 逐个查，或者一次性看所有通道状态：
SELECT * FROM performance_schema.replication_connection_status;其中
SOURCE_UUID 字段可对应各主库的 SELECT UUID() 结果，CHANNEL_NAME 即你定义的通道名，SERVICE_STATE 为 ON 才表示该通道 IO 线程正常运行。IO 线程异常时，LAST_IO_ERROR 是第一排查项；SQL 线程卡住则看 LAST_SQL_ERROR 和 EXECUTED_GTID_SET 是否滞后。多源复制真正难的不是配置，而是冲突预防和状态监控——每个通道独立运行、独立报错、独立延迟，一旦某个主库网络抖动或事务大，很容易 silently 滞后，而默认监控脚本往往只盯 Seconds_Behind_Master 这个字段，它只反映默认通道。别漏掉 performance_schema.replication_applier_status_by_coordinator 和 replication_applier_status_by_worker 这两张表。
