必须用 change replication filter 命令为每个 channel 单独配置，因 replicate-wild-do-table 是全局静态参数，启动时加载且不区分 channel，无法实现按源隔离过滤；修改 my.cnf 后需重启 mysqld 才生效，且已存在的 relay log 不会被重新过滤。
必须用 CHANGE REPLICATION FILTER 命令在从库上为每个 channel 单独配置，不能写进 my.cnf；且规则只对后续新拉取的 relay log 生效，已存在的中继日志不会被重新过滤。
为什么不能在 my.cnf 里配 replicate-wild-do-table？
MySQL 8.0+ 支持通道级复制过滤，但 replicate-wild-do-table 这类全局参数是进程启动时加载的，作用于整个 SQL 线程，不区分 channel。一旦配置，所有通道都会套用同一套规则，失去“按源隔离”的意义。
常见错误现象：
- 配置了 replicate-wild-do-table = db1.% 后，发现来自 channel 'master_a' 和 'master_b' 的 db1 表都被同步，无法做到「只让 master_a 同步 db1，master_b 只同步 db2」
- 修改 my.cnf 后仅执行 STOP REPLICA; START REPLICA;，规则不生效——因为该参数不支持运行时重载
正确做法是放弃 my.cnf 全局过滤，改用命令行方式为每个 channel 独立设置：
CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('db1.%') FOR CHANNEL 'master_a';CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('mysql.%', 'information_schema.%') FOR CHANNEL 'master_b';
通道级过滤的语法和限制
CHANGE REPLICATION FILTER 是 MySQL 8.0.22 引入的动态命令，但它不是万能的：它只影响 SQL 线程后续读取的 relay log，不清理已有中继日志，也不回滚已执行的事件。
使用场景举例：某 channel 刚接入一个新主库，但只想同步其中两张业务表，其他全跳过。
关键注意事项：
- 必须先
STOP REPLICA FOR CHANNEL 'xxx';，否则报错ERROR 3080 (HY000): Cannot change replication filter while replica is running - 规则格式严格为
('db_pattern.table_pattern')，中间英文点号不可省略，%匹配任意长度字符，_匹配单字符（如需字面量下划线，写成db1.log\_2025%） - 多个 pattern 用逗号分隔，但 MySQL 不保证匹配顺序；若冲突（比如同时设了
db1.%和db1.log_%），以最具体者为准 - 不支持混合白/黑名单逻辑：不能对同一 channel 同时设
REPLICATE_WILD_DO_TABLE和REPLICATE_WILD_IGNORE_TABLE，否则报错ERROR 3076 (HY000)
配置后如何验证是否生效？
不能只看 SHOW REPLICA STATUS FOR CHANNEL 'xxx' 里的 Replica_SQL_Running，那只能说明线程没挂；真正要确认的是“该 channel 是否真的跳过了不该同步的语句”。
实操建议：
- 在对应主库上执行一条明确会被过滤的语句，例如向
mysql.user插入测试数据（假设你设了REPLICATE_WILD_IGNORE_TABLE = ('mysql.%')） - 立刻在从库查
SELECT COUNT(*) FROM mysql.user;—— 若数量没变，说明过滤生效；若变了，说明规则未命中或未加载 - 检查
SHOW PROCESSLIST;中 SQL 线程状态，若出现Slave_SQL_Running_State: Waiting for dependent transaction to commit，大概率是 GTID 或事务依赖导致阻塞，和过滤无关 - 用
mysqlbinlog --base64-output=DECODE-ROWS -v /path/to/relay-log.000001手动解析中继日志，确认被过滤的事件是否根本没进入 relay log（注意：过滤发生在 SQL 线程重放阶段，不是 IO 线程拉取阶段）
最易被忽略的一点：通道级过滤只控制「SQL 线程是否执行」，不控制「IO 线程是否拉取」。即使你对某个 channel 设置了严格白名单，它的 IO 线程仍会把主库发来的全部 binlog 写进 relay log 文件——只是后续 SQL 线程读到不匹配的事件就直接跳过。这意味着磁盘空间、网络带宽、IO 压力并不会因此减少，纯粹是 CPU 层面的执行裁剪。
