多源复制中replicate_do_db对命名通道无效，仅作用于默认通道；必须用CHANGE REPLICATION FILTER...FOR CHANNEL显式为各通道单独配置过滤规则。
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 必须逐个通道指定。
实操建议：
- 优先用
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。多源复制的复杂度藏在通道边界里，每个通道都得当成独立从库来对待。
