多源复制迁移需先确保目标从库支持多源同步，关键配置为：master-info-repository和relay-log-info-repository必须设为TABLE、server-id全局唯一、relay_log_recovery=ON；导出须按主库分别执行，GTID环境用--set-gtid-purged=ON，非GTID用--master-data=2；严禁混用或合并导出。
不能直接“合并数据库”来实现多源复制迁移——多源复制是运行时的同步机制，不是数据导入工具。 你真正需要的是：先让目标从库能同时连上多个主库并持续同步，再处理表名/库名冲突、主键重叠、DDL 不一致等实际问题。
多源复制迁移前必须确认的三个配置项
MySQL 5.7+ 才原生支持多源复制，但光有版本不够，以下三项不满足，CHANGE MASTER TO ... FOR CHANNEL 会报错或静默失败：
-
master-info-repository = TABLE和relay-log-info-repository = TABLE必须设为TABLE（不能是FILE），否则通道元数据无法持久化 -
server-id在目标从库上必须唯一，且不能与任一主库的server-id冲突 -
relay_log_recovery = ON必须启用，否则崩溃重启后中继日志可能损坏，导致某个通道卡死
用 mysqldump 导出多个主库时的关键参数组合
导出不是简单拼库名，每个主库要单独 dump，并严格区分 GTID 状态。否则导入后 START SLAVE FOR CHANNEL 会因 position/GTID 不匹配而拒绝启动：
- 若所有主库都开启 GTID：
mysqldump -u root -p --all-databases --single-transaction --routines --triggers --set-gtid-purged=ON > full_dump.sql - 若部分主库未开 GTID：必须按库分开 dump，且对非 GTID 库加
--master-data=2，对 GTID 库加--set-gtid-purged=ON，混用会导致 GTID_EXECUTED 被覆盖 - 严禁使用
--databases db1 db2一次性导出多个库——这会让CREATE DATABASE语句出现在 dump 文件开头，而你实际需要的是各库在目标从库上已存在（否则复制通道可能找不到对应库）
启动多源复制后最常卡住的两个状态
SHOW SLAVE STATUS FOR CHANNEL 'xxx'\G 查看时，别只盯 Seconds_Behind_Master。这两个字段才是真瓶颈：
-
Slave_IO_Running: Connecting→ 多半是网络或权限问题：检查主库repl用户是否允许从目标从库 IP 连接；确认主库防火墙放行了 MySQL 端口；host字段是否用了通配符（如'repl'@'%'）而非具体 IP -
Slave_SQL_Running: No且Last_SQL_Error提示Table 'xxx' doesn't exist→ 说明该通道同步的某个表，在目标从库上不存在。这不是 dump 没导入，而是多源复制默认不自动建库建表。你必须提前在从库上CREATE DATABASE，并确保库名与主库完全一致（大小写敏感）
表名冲突和主键重复的实际应对方式
多源复制本身不做冲突检测，它只是把 binlog 事件原样重放。如果两个主库都有 user 表，且都往 id=1 插数据，从库必然报错停掉 SQL 线程：
- 最稳妥的做法：在从库上统一加前缀，比如主库 A 的
user表映射为a_user，主库 B 的映射为b_user。靠replicate-rewrite-db参数实现：replicate-rewrite-db="db_a->db_merged_a"，再配合replicate-do-db - 若必须共用一张表（如汇总统计），就得在应用层或中间件做主键隔离：主库 A 用
auto_increment_offset=1+auto_increment_increment=2，主库 B 用offset=2，避免 ID 冲突 -
slave-skip-errors只能跳过指定错误码（如1062主键冲突），但跳过后数据就失真了，仅限临时排障，不可长期开启
真正难的从来不是命令怎么写，而是每个主库的 binlog 格式、GTID 开关状态、表结构演进节奏是否一致。哪怕只有一个主库用 STATEMENT 格式写了 NOW()，它在从库重放时就可能和另一个 ROW 格式的主库产生时间偏差——这种细节，SHOW SLAVE STATUS 不会告诉你，得查 relay-log 文件本身。
