多源复制中各通道数据无法天然隔离，所有通道binlog事件共存于同一数据目录，需通过按通道分库（如db_a_prod、db_b_analytics）实现备份与恢复隔离，并禁用并行复制和谨慎使用gtid。
多源复制中各通道数据无法天然隔离
MySQL 多源复制（Multi-Source Replication）本身不提供通道级的数据隔离机制。所有通道写入的 binlog 事件最终都应用到同一个从库实例的同一套数据目录里，mysql.slave_master_info 和 mysql.slave_relay_log_info 表按通道名（如 channel_1、channel_2）分别记录状态，但数据层完全混存。这意味着：直接用 mysqldump --all-databases 会把所有通道来源的数据打包在一起，无法区分归属；恢复时若只想要回滚某一个主库的数据变更，没有额外标记就无从下手。
按通道逻辑分库是实现备份隔离的前提
最可靠的做法是在从库上为每个主源分配独立数据库名（而非共用同名库），例如：
- 主 A（192.168.1.10）→ 从库
db_a_prod - 主 B（192.168.1.11）→ 从库
db_b_analytics - 主 C（192.168.1.12）→ 从库
db_c_log
这样配置需在每个 CHANGE MASTER TO ... FOR CHANNEL 'xxx' 后，显式指定 replicate_rewrite_db 或使用 replicate_do_db + 应用层写库前缀控制。好处是：mysqldump -u root -p db_a_prod > backup_a.sql 就能精准捕获该通道全部数据，且恢复时不会污染其他通道数据。
备份时必须禁用并行复制与 GTID 冲突风险
多源复制下启用 slave_parallel_workers > 0 或全局 GTID（gtid_mode=ON）会导致以下问题：
-
mysqldump --single-transaction可能因事务跨通道交错而读到不一致快照 - GTID 集合（
gtid_executed）是全局合并的，无法反查某条语句来自哪个 channel - 恢复后执行
START SLAVE FOR CHANNEL 'x'可能因 GTID 已存在被跳过，造成数据丢失
建议生产环境对多源从库关闭并行复制（设 slave_parallel_workers=0），并避免开启 GTID；如必须用 GTID，应在备份前用 SHOW SLAVE STATUS FOR CHANNEL 'x'\G 记录对应 Retrieved_Gtid_Set 和 Executed_Gtid_Set，恢复后手动 SET GTID_NEXT='...'; BEGIN; COMMIT; 跳过已应用事务。
恢复时不能只靠 SQL 文件，必须重置通道位点
仅执行 mysql -u root -p db_a_prod 是危险的：它覆盖了数据，但没重置该通道的复制起点，后续 <code>START SLAVE FOR CHANNEL 'a' 会从中断处继续拉取——可能重复应用旧事件或跳过新事件。
正确流程是：
- 停掉对应通道：
STOP SLAVE FOR CHANNEL 'a'; - 导入备份：
mysql -u root -p db_a_prod - 根据备份时刻的主库 binlog 位置（需提前在主 A 上记下
SHOW MASTER STATUS），执行：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=154 FOR CHANNEL 'a'; - 再启动：
START SLAVE FOR CHANNEL 'a';
这个位点必须来自主 A 当时的真实日志位置，而不是从库当前的 Relay_Master_Log_File —— 因为多源下各通道 relay log 完全独立，混用会导致错位。
真正难的不是备份命令本身，而是让每个通道在逻辑、物理、元数据三个层面都“可识别、可定位、可还原”。一旦漏掉通道名、位点、库名映射中的任意一环，恢复就变成碰运气。
