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 是另一回事，别混。
评论(0)