主库用 binlog_do_db
和 binlog_ignore_db
过滤时，从库收不到预期的 binlog
这两个参数只在当前服务器的
USE数据库匹配时才生效，且基于语句复制（
STATEMENT）逻辑，对
INSERT INTO db1.table1 SELECT * FROM db2.table2这类跨库操作完全失效。更关键的是：它们作用于主库，但实际复制行为由从库的 SQL 线程解析事件后执行，而主库写入 binlog 时已丢弃被忽略的库操作——导致从库根本收不到任何相关事件，连过滤机会都没有。
实操建议：
除非你 100% 使用STATEMENT格式 + 每条语句前都显式
USE db_name，否则别碰这两个参数 MySQL 8.0+ 已将它们标记为 deprecated，未来版本会移除 真正可控、可预测的过滤必须放在从库侧
从库用 replicate_do_db
和 replicate_ignore_db
的坑
它们看似直观，但行为反直觉：不是“只复制/忽略某个库”，而是“仅当当前
USE库匹配时才执行该事件”。这意味着：
INSERT INTO db1.t1 VALUES (1)在
USE db2下执行 → 即使目标表是
db1.t1，也会被跳过
CREATE TABLE db1.t1 (id INT)在
USE db1下执行 → 被复制，但后续往
db1.t1插数据时若没
USE db1，仍可能被跳过 对
mysqldump --databases导出的多库脚本极不友好，容易漏复制
所以这些参数只适合极简场景（如单库应用 + 严格控制连接默认库），生产环境应避免。
推荐方案：用 replicate_wild_do_table
和 replicate_wild_ignore_table
通配符过滤才是可靠选择，它直接匹配事件中的库名和表名，与当前
USE无关。例如：
replicate_wild_do_table = app_% .% replicate_wild_ignore_table = mysql.%
这表示只复制库名以
app_开头的所有表，同时明确排除
mysql系统库所有表。注意语法细节： 格式固定为
db_pattern.table_pattern，中间是英文点号，不是下划线或斜杠
%匹配任意字符（包括空），
_匹配单个字符；
app\_prod.%中的反斜杠用于转义下划线字面量 多个规则用逗号分隔，但 MySQL 不保证顺序执行，冲突时以“最具体匹配”为准（如
app1.%和
app%.%同时存在，
app1.t会命中前者） 修改后需重启从库或执行
STOP SLAVE; START SLAVE;生效，不支持动态 SET
更灵活的替代：使用复制通道（Replication Channels）配合 CHANGE REPLICATION FILTER
MySQL 5.7+ 支持多通道复制，每个通道可独立配置过滤规则。相比全局变量，它允许按用途隔离策略，比如：
CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('app_core.%') FOR CHANNEL 'core_channel';
CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('app_log.%') FOR CHANNEL 'log_channel';这样两个通道可分别拉取不同业务子集，互不影响。优势在于：
规则可在线修改（无需重启），执行STOP SLAVE FOR CHANNEL 'xxx'; START SLAVE FOR CHANNEL 'xxx';即可重载 配合
START SLAVE UNTIL可做灰度同步、临时跳过某段 binlog 监控时可通过
performance_schema.replication_applier_status_by_coordinator查看各通道状态
唯一复杂点是管理成本上升——你需要显式创建通道、指定
MASTER_AUTO_POSITION=1或手动定位 GTID，且备份恢复时要确保通道配置也被保留。
