MySQL主从复制过滤规则：避开那些“坑”，选对可靠方案
replicate-do-db 和 replicate-ignore-db 的行为陷阱
先说一个核心认知：replicate-do-db 和 replicate-ignore-db 这两个参数，本质上并非全局的“数据库开关”。它们的工作机制，是基于SQL语句中显式的 USE 上下文来匹配的。这意味着什么？一旦你的SQL没有执行 USE db_name，或者玩起了跨库操作（比如 INSERT INTO other_db.t1 SELECT * FROM main_db.t2），replicate-do-db 就可能完全失效——从库会直接跳过整条语句，哪怕目标表明明在你的白名单里。
这种陷阱导致的错误现象很典型：你查看 SHOW SLA VE STATUS\G，发现复制延迟为0，一切看似正常，但数据就是莫名其妙地缺失了。或者更诡异的是，主库明明在写业务库，从库却同步了一堆日志表的数据。
- 这种行为在基于语句的复制（
binlog_format = STATEMENT）模式下是严格生效的。即便在ROW格式下，MySQL 5.7及以后版本会尝试根据实际修改的表来判断，但依然存在兼容性风险，不能完全依赖。 - 配置多个数据库时，不能用逗号偷懒。正确的做法是写成两行：
replicate-do-db = db1和replicate-do-db = db2。 - 规则优先级务必记牢：忽略规则（
replicate-ignore-db）的优先级永远高于白名单规则。两者冲突时，以ignore为准。
真正可靠的过滤方式：replicate-wild-do-table
那么，有没有更可控的方案？答案是肯定的。使用 replicate-wild-do-table 通过通配符按表名进行过滤，可以完美绕过对 USE 语句的依赖，这通常是生产环境更推荐的选择。举个例子，如果你只想同步 user_db 下的核心用户表，而忽略所有日志表和临时表，可以这样配置：
replicate-wild-do-table = user_db.users replicate-wild-do-table = user_db.profiles replicate-wild-ignore-table = user_db.log_%
这里有个关键点需要理解：replicate-wild-do-table 是“必须匹配任一规则才执行”的白名单逻辑，而 replicate-wild-ignore-table 是“匹配即跳过”的黑名单逻辑。两者可以共存，但黑名单（ignore）依然拥有更高的优先级。
- 通配符方面，仅支持
%（匹配任意数量字符）和_（匹配单个字符），不支持更复杂的正则表达式。 - 表名匹配是否区分大小写，取决于你的操作系统文件系统和
lower_case_table_names参数设置，配置时需保持一致。 - 需要警惕的是，DDL语句（例如
CREATE TABLE user_db.cache_2024）同样会被这些规则匹配，务必确认其行为符合你的预期。
过滤规则生效时机与验证方法
所有以 replicate-* 开头的参数，都必须在从库启动前写入配置文件（my.cnf）。如果是在运行时通过 SET GLOBAL 动态设置，那么必须随后执行 STOP SLA VE; START SLA VE; 来重启复制线程，规则才会被重新加载。仅仅执行 SET GLOBAL 是不会触发规则重载的。
如何验证规则确实生效了？千万别只看 Seconds_Behind_Master 这个指标。你应该：
- 检查
SHOW SLA VE STATUS\G输出中的Replicate_Do_DB、Replicate_Ignore_DB等字段，确认其显示的值与你的预期一致。 - 确保从库的
log_sla ve_updates参数设置为OFF（这是默认值），这样可以避免已经被过滤掉的事件，又被写入从库自身的binlog，导致数据在复杂的复制拓扑中二次传播。 - 使用
mysqlbinlog工具解析主库的binlog，确认待过滤的语句确实存在；然后再检查从库的relay log（通过SHOW SLA VE STATUS查看Relay_Log_File位置），确认该事件是否已被正确过滤。
替代方案：用 GTID + 应用层过滤或专用同步工具
当你的过滤逻辑变得非常复杂，比如需要按字段值、时间范围进行过滤，或者需要在同步过程中转换数据结构时，继续硬编码在MySQL配置里就会变得难以维护。这时候，就该考虑升级方案了：
- 可以考虑停用MySQL的原生复制，改为在应用层实现双写逻辑。或者，使用像Canal、Maxwell这样的工具抽取binlog，然后在应用层进行自定义的数据路由和过滤。
- 如果启用了GTID（
gtid_mode = ON），可以结合CHANGE MASTER TO ... IGNORE_SERVER_IDS的配置，并通过引入中间节点来实现链式过滤，不过这会让复制拓扑变得相对复杂。 - 在Docker或Kubernetes等动态环境下，使用
gh-ost或pt-online-schema-change这类在线改表工具时，要特别留意它们生成的临时表是否会被你的过滤规则误伤，导致变更失败。
最后提一个最容易被忽略的细节：从库上的 sql_log_bin = OFF 参数，控制的是当前会话的写入是否计入从库自身的binlog，但它完全不会改变复制过滤的行为。过滤，只发生在SQL线程解析relay log的那个阶段，和当前会话记不记binlog是两回事。理解这一点，能帮你避免很多不必要的困惑。
