replicate-do-db 经常失效，因其仅匹配 USE 指定的当前数据库，不解析 SQL 中的库名；在 ROW 格式下完全无效，且不支持跨库操作和逗号分隔多库配置。
replicate-do-db 在主从复制中为什么经常失效
它只对 USE 当前数据库的语句生效，不匹配跨库操作。比如执行 INSERT INTO other_db.t1 SELECT * FROM mydb.t2，即使设置了 replicate-do-db=mydb，这条语句仍会被跳过——因为 USE 的不是 mydb，而 Binlog 记录的是完整语句，MySQL 从库判断时只看当前默认库，不解析 SQL 内部表名。
常见错误现象：SHOW SLAVE STATUS\G 显示 Seconds_Behind_Master: 0，但目标库数据明显缺失；或者切换 USE 后同步行为突变。
- 仅适用于基于语句（
STATEMENT）或混合（MIXED）格式的 Binlog，ROW格式下该参数几乎不起作用 - 多个库需重复写多行配置，不能用逗号分隔：
replicate-do-db=db1和replicate-do-db=db2 - 若主库未显式
USE，而是全限定表名操作，该参数直接不触发过滤
真正可控的 Binlog 过滤方式：replicate-rewrite-db + filter-table 组合
想稳定同步特定库/表，得绕开 replicate-do-db 的语义缺陷，改用更底层的重写+白名单机制。核心是让从库把主库的写入“映射”到本地目标库，并配合 replicate-wild-do-table 精确控制表级粒度。
使用场景：跨环境同步（如只同步生产库中的 log_ 表）、多租户隔离、灰度发布验证。
-
replicate-rewrite-db="source_db->target_db"：重定向库名，要求主从库名不一致时必须用 -
replicate-wild-do-table=target_db.log_%：支持通配符，比replicate-do-table更灵活 - 所有
replicate-*配置必须在从库my.cnf中设置，并重启mysqld才生效（热加载不支持） - 注意顺序：重写发生在过滤之前，所以
wild-do-table应针对重写后的库名写
ROW 格式下唯一靠谱的过滤手段：从库端触发器 + 应用层丢弃
当 Binlog_format = ROW（推荐且默认），replicate-do-db 彻底失效，因为事件里没有 “当前库” 概念，只有 table_map_event 和 write_rows_event。此时 MySQL 自身不提供行级条件过滤能力。
可行路径只有两个：要么在从库上建 BEFORE INSERT/UPDATE/DELETE 触发器拦截非目标表操作；要么在应用消费 Binlog（如用 canal、maxwell）时做逻辑过滤后写入。
- 触发器方案简单但有性能损耗，且无法拦截 DDL；DDL 还得靠
replicate-ignore-ddl或外部工具拦截 - 应用层解析 Binlog 更灵活，能结合业务字段做过滤（如只同步
status=1的记录），但引入额外组件和运维复杂度 - 务必确认主库
binlog_row_image=FULL，否则从库触发器可能读不到完整旧值
测试过滤是否生效的三个必做动作
别只看 Seconds_Behind_Master，那只是 IO/SQL 线程没报错，不代表数据对得上。
- 在主库执行带库名前缀的语句：
INSERT INTO test_db.t1 VALUES (1);，然后立刻查从库对应表是否存在该记录 - 检查从库
SHOW SLAVE STATUS\G中的Replicate_Do_DB和Replicate_Rewrite_DB字段是否与配置一致（注意大小写） - 开启从库
log_warnings=2并观察错误日志，MySQL 会记录被跳过的事件，例如：Skipped database 'xxx' due to replicate-do-db rule
最容易被忽略的是：配置改了没重启从库服务，或者改了主库配置却以为影响从库行为。Binlog 过滤纯属从库行为，主库配置 binlog-do-db 是另一回事，别混。
