MySQL 8.4 多源复制如何避免通道串错：channel 状态、并行 worker 与冲突风险

一台汇聚副本同时接收订单库和报表库的变更时，最怕的不是某个通道同步慢，而是排查时把A通道的状态错当成B通道的，或者两个源端不小心往同一张表写入产生冲突。MySQL 8.4 原生支持多源复制，每个通道都可以配置独立的连接、中继日志和应用线程，先把通道之间的边界理清楚，再去调并行度才有实际意义。

先把两个 channel 的身份完全区分开

多源复制的每个通道各自从不同的源端接收变更。官方文档明确说明，一个副本实例不能创建多个通道连接同一个源端，因为源端是通过 server ID 识别副本节点，不是靠通道名做区分，强行配置同源多通道很容易引发状态错乱。

replica_parallel_workers 定义每个复制通道的应用worker数量，另外每个通道还会运行一个协调线程，负责从中继日志里取出事务再分发给工作线程。值为1的时候事务按单线程顺序执行，值为0在8.4版本里已经标记为不推荐使用，兼容旧版本脚本的时候要特别留意告警提示。

SHOW REPLICA STATUS FOR CHANNEL 'orders';\G
SHOW REPLICA STATUS FOR CHANNEL 'analytics';\G

SELECT CHANNEL_NAME, SERVICE_STATE, HOST, PORT
FROM performance_schema.replication_connection_status;

每个通道都有独立的并行应用队列

MySQL 8.4 默认使用4个复制worker、LOGICAL_CLOCK 和保序提交配置。多源场景下，这个worker计数是按每个通道单独生效的，订单通道开到8个worker，也不会替报表通道消化积压的同步任务。排查问题的时候先按channel维度记录 Relay_Log_Space、SQL线程状态和报错信息，再去看整机CPU负载，避免把单个通道的小问题误判成全节点复制故障。

保序提交开启后，更早进入队列的事务没提交完成，后面的worker哪怕已经执行完事务逻辑，也可能停在 Waiting for preceding transaction to commit 等待。这不是通道串线导致的异常，是该通道为了维持中继日志的原始提交顺序付出的等待成本。

通道级过滤器不能代替冲突规避设计

多源复制支持按通道单独配置过滤规则，但过滤只是决定哪些变更会被当前通道接收，不会自动解决两个源端同时更新同一行的冲突。更稳妥的方案是按业务域拆分表或者拆分库，明确每张表的唯一写入源，再把这条规则同步到全团队的变更审批流程里。

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'orders-db',
  SOURCE_PORT = 3306
FOR CHANNEL 'orders';

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'analytics-db',
  SOURCE_PORT = 3306
FOR CHANNEL 'analytics';

配置完成后分别执行 START REPLICA FOR CHANNEL，不要只执行不带channel后缀的命令就默认两个通道都运行正常。先拿小流量写入确认源端地址、源端UUID、通道名和过滤范围都符合预期，再开展后续压测。

提交顺序、大事务与跨通道冲突

生产环境的副本通常建议保持 replica_preserve_commit_order=ON 开启。这个配置能让每个通道内的多线程副本严格按中继日志的顺序提交，但不会帮你协调不同源端之间的写入顺序。两套源端都更新同一业务键的时候，最终产生的冲突还是要靠业务层的数据模型来处理。

还要重点关注 replica_pending_jobs_size_max 的配置阈值。当一个超大事务超过队列软上限时，副本可能先清空worker队列里的所有待执行小事务，再集中处理这个大事务，后面进来的所有事务也会被堵住。这种场景下继续加worker数量完全没用，正确的做法是拆分源端的大事务，或者把这类大事务放到单独的低峰发布窗口执行。

出问题时先定位具体故障通道

1. 先用带channel参数的状态命令确认是 orders 还是 analytics 出了问题。
2. 针对故障通道单独停止SQL应用线程，不要为了修一个通道直接停掉所有源端的同步任务。
3. 核对源端UUID、最后执行的GTID集合、Relay_Log_Space字段和具体错误码，确认问题是过滤规则配置错误还是数据写入冲突。
4. 不要直接用 replica_skip_errors 跳过报错兜底；多源复制没有内置冲突解决器，随意跳过错误很可能掩盖数据分叉问题。

STOP REPLICA SQL_THREAD FOR CHANNEL 'orders';
SHOW REPLICA STATUS FOR CHANNEL 'orders';\G
START REPLICA SQL_THREAD FOR CHANNEL 'orders';

常见问题

MySQL 8.4 多源复制可以让两个 channel 连接同一个 source 吗？

不可以。官方要求每个channel必须对应完全不同的源端实例，同一个源库不能通过多个通道被同一个副本节点识别。

每个 channel 都能单独设置 replica_parallel_workers 吗？

这个变量的生效范围是每个独立通道，因此多源副本的总worker数会随着通道数增加而叠加，配置的时候要统一核算CPU、内存和锁竞争的余量。

多源复制的过滤器能自动解决数据冲突吗？

不能。过滤器只会改变通道接收的变更范围，冲突检测和处理逻辑还是要由上层应用和数据模型来负责。

通道出错时能不能只重启一个通道？

可以使用带 FOR CHANNEL 参数的停止、查看和启动命令，先隔离故障通道，再核对它的源端信息和GTID状态做排查。

先做通道隔离，再调整并行度

多源复制真正麻烦的地方不是写出两条 CHANGE REPLICATION SOURCE TO 配置语句，而是保证每个通道的源端信息、过滤范围、GTID位点和故障操作流程都能独立核对。把业务域写入权限划分清楚、按通道单独留存状态记录，再根据每个队列的真实负载调整worker数量，才能避免出现“一个副本接了两套来源，最后没人能说清是谁写坏了数据”的被动局面。