如何设置主从同步时忽略特定的表_复制过滤规则排查

MySQL 主从同步怎么跳过某个表的复制

想让从库对主库的某张表“视而不见”？核心方法是在从库的 my.cnf 配置文件中，设置 replicate-ignore-table 或 replicate-wild-ignore-table 参数。这里有个关键点：配置完成后，必须重启 mysqld 服务才能生效，动态的 SET 命令在这里是无效的。

一个常见的误区是，直接在从库执行类似 SET GLOBAL replicate_ignore_table = ‘db1.t1’; 的命令。这完全行不通，因为这类变量是只读的，MySQL 本身就不支持在运行时动态修改复制过滤规则。

• replicate-ignore-table：用于精确匹配。格式必须是 db_name.table_name，大小写是否敏感取决于系统变量 lower_case_table_names 的设置。
• replicate-wild-ignore-table：支持通配符，比如 db1.log_% 或 test.%，灵活性更高，因此也更常用。
• 忽略多张表？ 需要写多行配置，每行一个，不能用逗号分隔。
• 验证生效：配置重启后，可以通过 SHOW SLA VE STATUS\G 命令，查看 Replicate_Ignore_Table 字段是否已更新。

为什么 replicate-do-db 和 replicate-ignore-db 很容易出错

这两个基于数据库名的过滤规则，其行为逻辑有点“反直觉”。它们判断的依据，是 SQL 线程当前正在使用的数据库（即 USE 语句指定的库），而不是 SQL 语句中显式写明的库名。

举个例子：主库执行 INSERT INTO db1.t1 …，但如果执行这条语句时，SQL 线程的当前库不是 db1（甚至是空），那么这条语句就可能被意外地放过或拦截。真正安全的场景极少，除非所有应用程序都严格遵守“先 USE db_x，再执行语句”的规范——这在现实中几乎不可能。

• DDL 语句同样受影响：像 CREATE TABLE db1.t2 这样的操作，也会因为当前数据库的判断问题，导致 replicate-ignore-db 规则不可靠。
• GTID 的隐患：如果启用了 GTID，使用这些基于库/表名的过滤规则，可能导致主从双方的 gtid_executed 和 gtid_purged 集合不一致，为后续的主从切换埋下隐患。
• 最佳实践：优先使用 replicate-wild-ignore-table，明确指定到表级别，行为更可预测。

从库已同步了不该同步的表，现在想补救

需要明确一点：复制过滤规则只对配置生效后新产生的复制事件起作用，它不会自动删除从库上已经存在的数据。如果那张表的数据已经被同步过来了，就需要手动介入清理。

• 第一步，停止复制：执行 STOP SLA VE;。
• 第二步，安全删除：确认从库的这张表没有业务写入（否则会导致数据丢失），然后执行 DROP TABLE db1.t1;。
• 第三步，重启复制：执行 START SLA VE;。此后，主库对该表的所有变更都不会再同步到从库。
• 一个后续风险：如果主库后续执行了 DROP DATABASE 或 TRUNCATE TABLE 等涉及该表的操作，从库会因为表不存在而报错（Table doesn‘t exist）。此时需要人工干预，例如使用 SET GLOBAL sql_sla ve_skip_counter = 1; 或通过 gtid_next 来跳过这个特定事务。

使用 replicate-wild-ignore-table 时的路径陷阱

通配符匹配的是 SQL 语句中间出现的库名和表名，而不是磁盘上的文件路径。不过，要特别注意下划线、点号这些字符的语义——MySQL 的 wild-ignore 采用的是简单的 shell 风格通配符，并非正则表达式。

• 忽略带日期的表：想忽略 log_20240101 这类表？写成 db1.log_* 即可，这里的下划线 _ 就是普通字符，无需转义。
• 正确使用通配符：想忽略 db1.user_info 和 db1.user_settings？用 db1.user_*。注意，不要写成 db1.user%，因为在 shell 通配规则里，% 在这里只是一个普通字符，不是通配符。
• 格式注意：配置值里不能包含空格。像 replicate-wild-ignore-table = db1.t1 , db1.t2 这样的写法会导致解析失败，必须换行或去掉空格。
• 大小写敏感：在 Linux 系统下默认是区分的，DB1.T1 和 db1.t1 会被视为两个不同的匹配目标。

MySQL主从同步中跳过某表复制需在从库my.cnf配置replicate-ignore-table或replicate-wild-ignore-table并重启mysqld；动态SET无效，过滤仅作用于SQL线程重放阶段，不删除已同步数据。

最后，有一个非常重要的机制需要理解：过滤规则仅作用于 SQL 线程的重放阶段。这意味着，主库的 binlog 事件仍然会被完整地传输到从库，并写入 relay log 中，只是在应用（执行）时被跳过了。所以，磁盘空间（Relay_Log_Space）的占用并不会减少，在排查复制延迟问题时，这一点很容易造成误判。