mysql如何配置主从复制过滤规则_replicate-do-db黑白名单

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是两回事。理解这一点，能帮你避免很多不必要的困惑。