MySQL 5.7+才支持CHANGE REPLICATION SOURCE TO多源复制，5.6需用CHANGE MASTER TO配合多个channel；版本低于5.7.17不建议使用，各通道须显式命名、server_id全局唯一、逐个启停、隔离写入以防冲突，并通过performance_schema按channel监控状态。
MySQL 5.7+ 才支持 CHANGE REPLICATION SOURCE TO 多源配置
MySQL 5.6 的多源复制靠的是 CHANGE MASTER TO + 多个 channel，但语法和行为和 5.7+ 差很多；5.7 起统一为 SOURCE 术语，且 channel 成为必需参数。用错版本会直接报 ERROR 1235 (HY000): This version of MySQL doesn't yet support 'multiple triggers with the same action time and event for one table' 这类看似无关的错误——其实是解析 FOR CHANNEL 失败导致的语法误判。
实操建议：
- 先确认版本：
SELECT VERSION();，低于 5.7.17（推荐 5.7.28+ 或 8.0.22+）别硬上多源 - 5.7 中每个通道必须显式命名，比如
FOR CHANNEL 'src_a'，不能省略 - 从库的
server_id必须全局唯一，且不能和任一主库重复，否则 IO 线程启动失败，日志里只写Could not initialize master info structure，不提示具体原因
每个通道要独立执行 START REPLICA，不能靠 START REPLICA 一把梭
这是最常踩的坑：执行完所有 CHANGE REPLICATION SOURCE TO ... FOR CHANNEL 'x' 后，直接敲 START REPLICA，结果只有默认通道（空 channel 名）启动，其余静默失败。MySQL 不会报错，SHOW REPLICA STATUS 也只显示默认通道状态，其他通道压根不列出来。
实操建议：
- 逐个启动：
START REPLICA FOR CHANNEL 'src_a';、START REPLICA FOR CHANNEL 'src_b'; - 查状态必须带 channel：
SHOW REPLICA STATUS FOR CHANNEL 'src_a'\G，否则看不到非默认通道的Seconds_Behind_Master或IO_Running - 停止单个通道也一样：
STOP REPLICA FOR CHANNEL 'src_b';，别用不带FOR CHANNEL的全局命令，它只影响默认通道
冲突处理靠 replica_parallel_workers > 0 和 replica_preserve_commit_order = ON 不够用
多源复制不是自动“合并”数据。如果两个主库都往同一个库表写（比如都写 log.events），从库大概率会因主键/唯一键冲突卡住，SQL_Running 变 No，错误是 ERROR 1062 (23000): Duplicate entry '123' for key 'PRIMARY'。并行复制参数只管单通道内事务调度，不管跨通道冲突。
实操建议：
- 业务层隔离写入：不同主库写不同库（如
app_a.*/app_b.*），或不同表前缀（src_a_user/src_b_user） - 真要合表，得在主库做写路由，或用
replicate_rewrite_db重映射库名（但不支持正则，且只对USE和CREATE DATABASE生效） -
replica_skip_errors是危险操作，跳过1062可能掩盖更严重的逻辑错位，慎用
监控必须按 channel 拆开看，performance_schema.replication_connection_status 是关键
SHOW REPLICA STATUS 查单个通道还行，但批量管理几十个 channel 时，手动 \G 太慢，而且字段不规整。真正可靠的实时状态在 performance_schema 表里，尤其 replication_connection_status 和 replication_applier_status_by_coordinator。
实操建议：
- 查所有通道连接状态：
SELECT CHANNEL_NAME, SERVICE_STATE, LAST_HEARTBEAT_TIMESTAMP FROM performance_schema.replication_connection_status; - 查各通道 SQL 线程进度：
SELECT CHANNEL_NAME, WORKER_ID, LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP FROM performance_schema.replication_applier_status_by_worker; - 注意
LAST_HEARTBEAT_TIMESTAMP为空 ≠ 断连，可能是主库没开master_heartbeat_period；得结合SERVICE_STATE和CONNECTION_RETRY_INTERVAL综合判断
多源复制里，“通道”不是抽象概念，是独立的 IO 线程 + 独立 relay log + 独立 SQL 线程。漏掉任何一个 channel 的状态检查，就等于放任一个黑盒在后台跑。
