如何设置主从同步时忽略特定的表_复制过滤规则排查
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)的占用并不会减少,在排查复制延迟问题时,这一点很容易造成误判。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
MySQL报错Unknown column in field list_检查SQL字段名拼写
MySQL报错“Unknown column xxx in field list ”的深度解析与实战排查 遇到“Unknown column ‘xxx’ in ‘field list’”这个报错,很多人的第一反应是检查拼写。这没错,但事情往往没那么简单。这个错误的本质,是MySQL在解析你的S
mysql如何查询字段值为空字符串的记录_空值与空串的区别判断
查空字符串应使用 WHERE column_name = ,但该条件无法匹配 NULL;需同时用 IS NULL 或 IFNULL() 处理,且 CASE 判断中 IS NULL 必须优先于 = 。 直接用 = 查空字符串,但别误判 NULL 想找出字段值为空字符串的记录,最直接的写法
mysql如何判断字段是否满足邮箱正则格式_REGEXP复杂匹配
不推荐用 MySQL 原生 REGEXP 做严格邮箱校验,因其正则引擎功能有限、不支持关键特性且无法覆盖 RFC 5322 复杂规则,仅适合粗筛明显非法值,严格校验应交由应用层完成。 MySQL 用 REGEXP 判断邮箱格式是否可靠? 开门见山,先说核心结论:不推荐依赖 MySQL 原生的 REG
Oracle RAC如何处理脑裂(Split-Brain)?配置冗余私网心跳
Oracle RAC如何真正预防脑裂?三重心跳与多数派原则是关键 一个常见的误解是,为Oracle RAC增加一块私联网卡就能高枕无忧地防止脑裂。事实并非如此。RAC本身并不“处理”已经发生的脑裂,而是通过一套精密的三重心跳机制、Quorum(法定人数)算法和IO Fencing(I O隔离)来主动
mysql读写分离配置_MyISAM与InnoDB在主从环境表现
MyISAM 与 InnoDB 在主从环境表现 MyISAM 表在 MySQL 主从复制中不可靠,因不支持事务导致 binlog 与表更新非原子,易丢数据;InnoDB 凭借 crash-safe 和 XID 关联机制保障复制一致性,是唯一稳妥选择。 MyISAM 表在 MySQL 主从复制中会丢数
- 日榜
- 周榜
- 月榜
1
2
3
4
5
6
7
8
9
10
相关攻略
2015-03-10 11:25
2015-03-10 11:05
2021-08-04 13:30
2015-03-10 11:22
2015-03-10 12:39
2022-05-16 18:57
2025-05-23 13:43
2025-05-23 14:01
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程
热门话题

