MySQL Binlog过滤：为什么replicate-do-db经常“失灵”及可靠替代方案
replicate-do-db 在主从复制中为什么经常失效
先说一个核心痛点：replicate-do-db 这个参数，它的工作逻辑有点“死板”。它只认执行语句时 USE 命令指定的那个“当前数据库”。一旦遇到跨库操作，它就“罢工”了。
举个例子就明白了。假设你在主库执行这条语句：INSERT INTO other_db.t1 SELECT * FROM mydb.t2。即使你在从库上设置了 replicate-do-db=mydb，希望同步 mydb 库，这条语句依然会被无情地跳过。原因就在于，Binlog里记录的是完整的SQL语句，而从库在判断时，只会看执行这条语句时默认的数据库（USE 的是什么库），它并不会去解析SQL语句内部的库名和表名。
这就导致了一些典型的“灵异”现象：你用 SHOW SLA VE STATUS\G 查看，Seconds_Behind_Master 显示为0，好像同步一切正常，但目标库里的数据就是莫名其妙地缺失。或者，一旦切换了 USE 的数据库，同步行为就立刻变了样。
- 它的生效范围很窄：仅对基于语句（
STATEMENT）或混合（MIXED）格式的Binlog有点用，在目前主流的ROW格式下，这个参数基本就“躺平”了。 - 配置方式也不够灵活：想同步多个库？不能用逗号分隔，必须老老实实写多行配置：
replicate-do-db=db1和replicate-do-db=db2。 - 还有一个致命缺陷：如果主库的SQL语句全程使用“库名.表名”这种全限定名，而没有显式地
USE某个库，那么这个过滤参数压根就不会被触发。
真正可控的 Binlog 过滤方式：replicate-rewrite-db + filter-table 组合
那么，想要稳定、精确地同步特定库或表，该怎么办？答案是绕开 replicate-do-db 的语义陷阱，采用一套更底层、更可控的组合拳：库名重写加表级白名单。
这套方案的核心思路是，让从库先把主库的写入操作“映射”到本地的目标库，然后再用通配符精确控制需要同步哪些表。这样一来，无论主库的SQL怎么写，从库都能按我们设定的规则来执行。
这种组合在哪些场景下特别有用呢？比如，你只想从生产库同步所有以 log_ 开头的日志表到报表库；或者，在多租户架构中做数据隔离；再或者，在灰度发布时，只同步部分关键表到验证环境。
replicate-rewrite-db="source_db->target_db"：这是“重定向”的关键。当主从库名不一致，或者你想把主库的A库同步到从库的B库时，就必须用它。replicate-wild-do-table=target_db.log_%：这是“过滤器”。它支持通配符（%和_），比只能写死表名的replicate-do-table灵活得多。- 务必注意：所有这些
replicate-*配置，都必须写在从库的my.cnf配置文件里，并且重启mysqld服务才能生效。MySQL目前不支持这类参数的热加载。 - 还有一个至关重要的顺序问题：库名“重写”发生在表名“过滤”之前。所以，你的
wild-do-table规则，必须针对重写之后的库名来写。
ROW 格式下唯一靠谱的过滤手段：从库端触发器 + 应用层丢弃
现在，我们面对一个更普遍的现实：Binlog_format 设置为 ROW（这也是官方推荐且现在默认的格式）。在这个模式下，replicate-do-db 就彻底“失灵”了。因为ROW格式的Binlog事件里，根本没有“当前数据库”这个概念，它只记录“哪个表的哪行数据变了”。
这时候，MySQL自身提供的过滤能力几乎为零。想要实现行级或表级的条件过滤，只剩下两条路可走。
第一条路，是在从库上动手术，创建 BEFORE INSERT/UPDATE/DELETE 触发器。在数据真正落盘前，由触发器来判断是否属于需要同步的表，如果不是，就拦截掉。这个方法简单直接，但缺点也很明显：对性能有损耗，而且触发器管不了DDL（比如删表、改表结构）操作。对付DDL，还得靠 replicate-ignore-ddl 这类参数或者外部工具。
第二条路，是把过滤逻辑上移到应用层。使用 canal、maxwell 等中间件先解析主库的Binlog，在应用层代码里做好复杂的过滤逻辑（比如，只同步状态为1的记录），再把处理后的数据写入从库。这条路灵活性最高，能结合具体业务字段做精细过滤，但代价是引入了额外的组件，增加了系统的运维复杂度。
- 如果选择触发器方案，有一个前置检查必不可少：务必确认主库的
binlog_row_image参数设置为FULL。否则，从库的触发器可能读不到更新前的完整旧值，导致判断逻辑出错。
测试过滤是否生效的三个必做动作
配置好了，千万别以为就万事大吉。过滤规则生不生效，必须经过严格测试。别只盯着 Seconds_Behind_Master，这个值为0只能说明IO线程和SQL线程没报错，不代表数据同步对了。
你需要做下面这三件事：
- 模拟跨库操作：在主库执行一条带库名前缀的语句，比如
INSERT INTO test_db.t1 VALUES (1);。执行后，立刻到从库上检查对应的表里有没有这条记录。这是检验replicate-do-db缺陷最直接的方法。 - 核对配置状态：在从库执行
SHOW SLA VE STATUS\G，仔细查看输出中的Replicate_Do_DB和Replicate_Rewrite_DB字段。确保这里显示的内容，和你配置文件里写的一模一样（注意，MySQL对大小写敏感）。 - 开启详细日志：在从库配置文件中设置
log_warnings=2，然后观察MySQL的错误日志。如果配置生效，MySQL会明确记录哪些事件因为过滤规则被跳过了，日志里会出现类似Skipped database 'xxx' due to replicate-do-db rule这样的信息。
最后，提醒一个最容易踩的坑：改了从库配置，却忘了重启服务。或者，错误地在主库上修改配置，以为能影响从库的过滤行为。必须牢记：Binlog过滤纯粹是从库的行为，所有 replicate-* 参数都配在从库。主库那边类似的 binlog-do-db 参数，控制的是主库自己记录哪些Binlog，完全是另一回事，千万别搞混了。
