迁移多源复制需确保各主库复制链独立重建。1. 明确每主库连接信息与binlog/GTID位点；2. 新从库配置唯一server-id及GTID等参数；3. 用mysqldump或XtraBackup导出主库数据并记录一致性位点；4. 导入数据后，为每个主库创建独立复制通道并指定MASTER_AUTO_POSITION=1（GTID模式）；5. 启动各通道复制并验证Slave_IO_Running、Slave_SQL_Running状态正常。GTID可简化位点管理，减少配置错误风险。
在 MySQL 中迁移多源复制（Multi-Source Replication）环境，核心是确保多个主库（Master）到一个从库（Slave）的复制关系在新环境中正确重建。迁移过程需要谨慎处理配置、数据一致性与复制位点。以下是具体操作步骤和注意事项。
理解多源复制架构
多源复制允许一个从库同时从多个主库接收并应用二进制日志。每个主库在从库上都有独立的复制通道（channel），因此迁移时必须分别处理每条复制链。
迁移前需明确以下信息：
- 每个主库的 IP、端口、复制用户权限
- 每个主库当前的 binlog 文件名和位置（或 GTID 位置）
- 从库上各复制通道的状态（SHOW SLAVE STATUS FOR CHANNEL 'xxx'）
- 是否启用 GTID（推荐使用 GTID 简化迁移）
准备目标从库环境
在新的从库服务器上安装 MySQL，并配置支持多源复制的基本参数。
关键配置项包括：
- server-id：必须唯一，不能与任何主库或其他从库冲突
- enforce-gtid-consistency = ON
- gtid-mode = ON（如使用 GTID）
- master-info-repository = TABLE
- relay-log-info-repository = TABLE
- binlog-format = ROW（建议）
这些设置确保复制元数据持久化到表中，避免因文件丢失导致状态不一致。
导出与恢复主库数据
为保证数据一致性，应使用一致性备份方式导出每个主库的数据。
推荐方法：
- 使用 mysqldump --single-transaction --master-data=2 --routines --triggers 导出逻辑备份
- 记录导出时每个主库的 binlog 位置或 GTID 集合
- 若使用 XtraBackup，执行物理备份并获取对应的 binlog 位点
将各主库数据导入新从库。注意：导入时不启动复制，仅恢复数据。
配置多源复制通道
在新从库上为每个主库创建独立的复制通道。
示例命令：
CHANGE MASTER TOMASTER_HOST='master1-host',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1
FOR CHANNEL 'master1';
重复上述命令，为其他主库配置不同 channel 名称（如 'master2'、'master3'）。
如果未使用 GTID，需指定 MASTER_LOG_FILE 和 MASTER_LOG_POS。
启动并验证复制
逐个启动复制通道：
START SLAVE FOR CHANNEL 'master1';检查每个通道状态：
SHOW SLAVE STATUS FOR CHANNEL 'master1'\G确认以下字段正常：
- Slave_IO_Running: Yes
- Slave_SQL_Running: Yes
- Last_Error 为空
- Seconds_Behind_Master 逐渐减少
所有通道运行正常后，表示迁移成功。
基本上就这些。关键是每个主库的位点要准确，配置不能混淆，GTID 能大幅降低复杂度。迁移期间建议暂停写入或控制主库变更，以减少数据偏差风险。
