MySQL多源复制本身不汇总数据，仅提供多个独立binlog拉取与回放通道；真正实现汇总需手动解决库表映射、同名冲突及业务聚合。
MySQL 多源复制本身不汇总数据，它只提供多个独立的 binlog 拉取与回放通道；真正实现“汇总”，必须靠你手动解决库表映射、同名冲突和业务逻辑聚合。
确认 MySQL 版本与核心参数是否就绪
低于 5.7.17 的版本存在 FOR CHANNEL 解析缺陷，执行时可能误报 ERROR 1235；8.0.23+ 已彻底弃用 CHANGE MASTER TO，必须用 CHANGE REPLICATION SOURCE TO。关键检查项：
-
SELECT VERSION();返回至少5.7.17（推荐8.0.33+） -
SHOW VARIABLES LIKE 'log_bin';必须为ON（从库也得开 binlog） -
SHOW VARIABLES LIKE 'server_id';必须是非零且全局唯一（所有主库 + 从库不能重复） -
master_info_repository和relay_log_info_repository必须设为TABLE，否则重启后通道元数据丢失
每个主库必须绑定语义化 channel 名并启用 GTID
漏写 FOR CHANNEL 或复用空名/非法字符名（如含空格、斜杠），会直接报错 ERROR 1238 或静默覆盖已有通道。示例配置：
CHANGE REPLICATION SOURCE TO SOURCE_HOST = '192.168.1.10', SOURCE_USER = 'repl_a', SOURCE_PASSWORD = 'p@ssw0rd!', SOURCE_PORT = 3306, SOURCE_AUTO_POSITION = 1 FOR CHANNEL 'prod_orders';
注意：
- 通道名大小写敏感，建议用
'prod_orders'、'analytics_logs'这类语义化命名，别用'master1' -
SOURCE_AUTO_POSITION = 1是强制要求（即 GTID 模式），否则主库切换后极易因 position 错位中断 - 密码含特殊字符（如
@、/）必须原样单引号包裹，MySQL 不做 URL 解码 - 执行前务必先
STOP REPLICA;，否则并发修改可能触发ERROR 3080
查状态、启停必须按 channel 操作，不能一把梭
SHOW REPLICA STATUS; 默认只显示空字符串通道（即未命名通道），其他通道完全不反映——这是最常被忽略的故障点。正确做法：
- 查单个通道：
SHOW REPLICA STATUS FOR CHANNEL 'prod_orders'; - 重点关注字段：
Retrieved_Gtid_Set（是否持续增长）、Executed_Gtid_Set、Replica_IO_Running和Replica_SQL_Running是否为Yes - 启动指定通道：
START REPLICA FOR CHANNEL 'prod_orders';；只执行START REPLICA;不会启动任何命名通道 - 若某通道卡住且
Seconds_Behind_Source持续增长，先检查对应主库的binlog_format是否为ROW—— 只要有一个是STATEMENT或MIXED，该通道就会静默卡在Waiting for dependent transaction to commit
真正的“汇总”不在复制配置里，而在你后续的动作中
多源复制完成后，所有数据只是分别回放到各自库表中（比如 orders_db.orders 和 users_db.users），不会自动合并成一张宽表或重命名避免冲突。你必须额外做：
- 用
replication filter（如REPLICATE_DO_DB）限制只拉指定库，避免不同主库的同名库互相覆盖 - 在从库上建视图或物化表，把多个源的同结构表 union 起来（注意主键冲突需加来源标识字段）
- 用应用层脚本或 Flink/CDC 工具消费各通道的 binlog，做字段映射、去重、聚合后再写入目标宽表
- 如果主库开了
log-slave-updates，从库自己也能作为中间节点再级联出去，但务必确认server_id全局唯一，否则 GTID 会混乱
最容易被忽略的是：你以为配置完就“汇总好了”，其实只是管道通了；后面那层业务逻辑，才是决定数据能不能真用起来的关键。
