迁移多源复制需确保各主库复制链独立重建。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 位点

将各主库数据导入新从库。注意：导入时不启动复制，仅恢复数据。

配置多源复制通道

在新从库上为每个主库创建独立的复制通道。

示例命令：

重复上述命令，为其他主库配置不同 channel 名称（如 'master2'、'master3'）。

如果未使用 GTID，需指定 MASTER_LOG_FILE 和 MASTER_LOG_POS。

启动并验证复制

逐个启动复制通道：

检查每个通道状态：

确认以下字段正常：

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes
• Last_Error 为空
• Seconds_Behind_Master 逐渐减少

所有通道运行正常后，表示迁移成功。

基本上就这些。关键是每个主库的位点要准确，配置不能混淆，GTID 能大幅降低复杂度。迁移期间建议暂停写入或控制主库变更，以减少数据偏差风险。