如何在MySQL多源复制中正确配置通道过滤规则？-mysql教程-PHP中文网

多源复制中replicate_do_db对命名通道无效，仅作用于默认通道；必须用change replication filter...for channel显式为各通道单独配置过滤规则。

如何在mysql多源复制中正确配置通道过滤规则？

multi-source replication 中 replicate_do_db 不起作用？

在多源复制里直接复用单源的 replicate_do_db 配置，基本等于没配——它只对默认通道（匿名通道）生效，其他命名通道完全无视。MySQL 8.0+ 虽支持通道级过滤，但必须显式绑定到具体通道名，否则所有 replicate_* 全局参数都只影响默认通道。

常见错误现象：

配置了 replicate_do_db = app_core，但来自 channel_a 的变更仍同步了 app_log 库
SHOW SLAVE STATUS 显示 SQL 线程运行正常，但从库却多了不该有的表

正确做法是：用 CHANGE REPLICATION FILTER 命令为每个通道单独设置，例如：

CHANGE REPLICATION FILTER REPLICATE_DO_DB = (app_core) FOR CHANNEL 'channel_a';
CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE = (sys.% , mysql.%) FOR CHANNEL 'channel_b';

注意：

必须在从库上执行，且该通道已存在（即已完成 CHANGE MASTER TO ... FOR CHANNEL 'xxx'）
命令不写入配置文件，重启后失效；如需持久化，得在 my.cnf 中用 replicate-do-db = app_core + replicate-ignore-table = sys.% 并配合 default_replication_channel = channel_a（仅限 MySQL 8.0.23+）
多个通道不能共用同一套过滤规则；REPLICATE_DO_DB 是白名单，未列出的库一律被跳过，哪怕语句里显式写了库名

为什么 replicate_wild_ignore_table 在通道里也得重配？

通配符过滤（如 sys.%、performance_schema.%）在多源场景下同样不会自动继承。即使你在全局配置了 replicate_wild_ignore_table = 'sys.%'，channel_b 依然会同步主库 sys 库的 DDL——因为该参数只作用于默认通道。

原因很简单：MySQL 把每个通道当作独立复制实例来管理，IO 线程拉取 binlog、SQL 线程解析执行、过滤器匹配，三者全部按通道隔离。所以 replicate_wild_ignore_table 必须逐个通道指定。

实操建议：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

优先用 REPLICATE_WILD_IGNORE_TABLE 而非 REPLICATE_IGNORE_TABLE，前者支持通配符，覆盖更全
系统库过滤务必覆盖全部通道，尤其 mysql 和 sys：一条漏掉就可能让从库用户权限错乱或监控失效
不要依赖 replicate_ignore_db，它在任何通道下都不可靠——显式库名操作（如 INSERT INTO app_log.audit_log）永远绕过它

配置后怎么验证通道过滤是否生效？

别只看 SHOW SLAVE STATUS\G 里的 Seconds_Behind_Master，那只能说明复制没卡住，不能证明数据没被错同步。

真正有效的验证方式是：

在主库对应源上，执行跨库操作：USE db1; INSERT INTO db2.log_table VALUES (1, 'test');，然后查从库 db2.log_table 是否为空
检查从库 binlog（如果开启）：用 mysqlbinlog --base64-output=DECODE-ROWS -v 查看 SQL 线程是否真的跳过了被过滤的事件
对每个通道单独查状态：SHOW SLAVE STATUS FOR CHANNEL 'channel_a'\G，确认 Replicate_Do_DB 和 Replicate_Ignore_Table 字段值与预期一致

容易忽略的一点：过滤规则只对新拉取的 binlog 事件生效。如果 IO 线程已缓存了旧事件（比如刚改完配置还没来得及拉新日志），SQL 线程仍会执行那些未被过滤的旧事件。稳妥做法是先 STOP SLAVE FOR CHANNEL 'xxx';，等 SQL 线程追平再 START。

GTID 模式下通道过滤要特别注意什么？

当多个源都启用了 GTID，且它们之间存在相同事务（比如钻石拓扑中两个主库都执行了同一逻辑的初始化脚本），过滤规则必须完全一致。否则一个通道过滤掉了某事务，另一个通道同步过来，就会导致 GTID set 不匹配，复制中断报错 Could not execute Write_rows event on table xxx; Error_code: 1032。

关键约束：

所有通道对同一库/表的过滤策略必须相同，不能 A 通道 DO、B 通道 IGNORE
如果某个源的 binlog 包含跨库 DDL（如 CREATE DATABASE IF NOT EXISTS db2），而你只在该通道设置了 REPLICATE_DO_DB = (db1)，这个 DDL 会被跳过——从库就不会创建 db2，后续往 db2 写数据直接失败
DDL 过滤比 DML 更敏感，建议把建库、建表类操作统一放在专用初始化通道，避免混在业务通道里被误过滤

最麻烦的不是配错，而是配了一半——比如只给 channel_a 加了过滤，忘了 channel_b。多源复制的复杂度藏在通道边界里，每个通道都得当成独立从库来对待。