MySQL主从复制过滤配置的完整方案

前言：为什么需要主从复制过滤？

在实际生产环境中，MySQL 主从复制架构几乎是标配，但默认的全量同步往往会带来不必要的资源消耗 —— 比如日志表、测试表的数据同步，不仅占用从库磁盘空间，还会增加网络传输压力。因此，精细化控制同步范围（只同步核心数据、忽略非必要表 / 库）就显得尤为重要。

最近刚好在优化公司的主从架构，整理了一套完整的过滤配置实验方案，从环境准备到六种核心场景测试，全程实操验证，今天就把这些干货分享给大家～

一、实验环境准备（基础铺垫不能少）

首先得有一个正常运行的 MySQL 主从架构（主从已实现基础同步），我这里用的是 MySQL 8.0 版本，操作系统是 CentOS 7。

1.1 主库：创建测试数据

为了验证不同过滤规则，我特意创建了 2 个库、4 张表，包含业务表、日志表，方便后续区分测试：

-- 创建测试库

create database db1;

create database db2;

-- db1库：业务表+日志表（模拟真实场景）

use db1;

create table table_01(id int not null auto_increment primary key, name varchar(10));

create table table_02(id int not null auto_increment primary key, name varchar(10));

create table log_01(id int not null auto_increment primary key, name varchar(10)); -- 拟忽略的日志表

-- db2库：普通测试表

use db2;

create table test_01(id int not null auto_increment primary key, name varchar(10));

然后插入随机测试数据（用 MD5 生成随机字符串，不用手动造数据，效率超高）：

insert into db1.table_01(name) values (SUBSTRING(MD5(RAND()), 1, 10));

insert into db1.table_02(name) values (SUBSTRING(MD5(RAND()), 1, 10));

insert into db1.log_01(name) values (SUBSTRING(MD5(RAND()), 1, 10));

insert into db2.test_01(name) values (SUBSTRING(MD5(RAND()), 1, 10));

1.2 从库：验证初始同步

这一步很关键！必须先确认主从基础同步正常，不然后续过滤测试就没意义了。在从库执行查询：

select * from db1.table_01;

select * from db1.table_02;

select * from db1.log_01;

select * from db2.test_01;

如果都能查到数据，说明主从架构没问题，可以开始过滤配置了～

二、六种核心过滤方案（场景化实操）

所有过滤规则都在从库配置，记住一个通用流程：停止SQL线程 → 配置规则 → 重启SQL线程 → 测试效果 → 清理规则，避免规则残留影响后续测试。

2.1 方案 1：只复制某一个库（REPLICATE_DO_DB）

适用场景：只需要同步核心业务库（比如 db1），非核心库（如 db2）无需同步。

-- 临时配置（不用重启，测试用超方便）

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_DO_DB=(db1);

start slave sql_thread;

show slave status\G; -- 查看Filter参数是否生效

如果需要长期生效，就要改配置文件（记得重启服务）：

vim /data/mysql/conf/my.cnf

replicate-do-db=db1  # 新增配置

systemctl restart mysqld

测试结果：主库往 db1 插数据同步成功，db2 插数据从库无反应，符合预期～

2.2 方案 2：忽略某个库（REPLICATE_IGNORE_DB）

适用场景：除了某个库（比如日志库 db1），其他库都要同步。

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB=(db1);

start slave sql\_thread;

测试感悟：这个规则适合把测试库、日志库排除在外，减少从库压力，亲测好用！

2.3 方案 3：只复制指定表（REPLICATE_DO_TABLE）

适用场景：同一库下只需要同步核心表（比如 db1.table_01），其他表忽略。

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_DO_TABLE=(db1.table_01); -- 必须写"库名.表名"

start slave sql_thread;

注意：如果只写表名会失效！之前踩过这个坑，大家一定要注意～

2.4 方案 4：忽略指定表（REPLICATE_IGNORE_TABLE）

适用场景：同步某库大部分表，但忽略日志表、临时表（比如 db1.log_01）。

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE=(db1.log_01);

start slave sql_thread;

实操心得：日志表数据量大且无需备份，用这个规则能节省大量磁盘空间～

2.5 方案 5：通配符匹配同步表（REPLICATE_WILD_DO_TABLE）

适用场景：同步某库下符合前缀 / 后缀规则的表（比如 db1 下所有 table 开头的表）。

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE=('db1.table%'); -- 通配符%匹配任意字符

start slave sql_thread;

配置文件持久化（不用加引号）：

replicate-wild-do-table=db1.table%

测试效果：table_01、table_02 都能同步，log_01 被忽略，批量匹配超高效！

2.6 方案 6：通配符忽略表（REPLICATE_WILD_IGNORE_TABLE）

适用场景：忽略某库下符合规则的表（比如 db1 下所有 table 开头的表）。

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE=('db1.table%');

start slave sql_thread;

使用建议：如果需要批量排除同类表，这个规则比逐个写 REPLICATE_IGNORE_TABLE 更方便。

三、实验总结（快速选型指南）

整理了一张对比表，大家可以根据业务场景直接选型：

四、避坑指南（实操经验分享）

1. 配置优先级：临时配置（CHANGE REPLICATION FILTER）比配置文件优先级高，测试时用临时配置，确定后再写配置文件。
2. 规则冲突：如果同时配置 “只复制” 和 “忽略”，忽略规则优先级更高！比如既配置了 REPLICATE_DO_DB=db1，又配置了 REPLICATE_IGNORE_TABLE=db1.table_01，那么 table_01 会被忽略。
3. 大小写问题：Linux 环境下 MySQL 默认区分表名大小写，配置时要和实际表名一致（比如 table_01 不能写成 Table_01），否则规则失效！
4. 重启影响：临时配置重启从库后会丢失，生产环境一定要用配置文件持久化。
5. 数据清理：实验结束后记得在主从库同时删除测试库（drop database db1; drop database db2;），避免残留数据干扰。

最后

以上就是 MySQL 主从复制过滤配置的全部实操内容啦～ 其实过滤规则不难，关键是根据业务场景选对方案，并且注意避坑。如果大家有其他场景的过滤需求，或者在实操中遇到问题，欢迎在评论区交流探讨！

以上就是MySQL主从复制过滤配置的完整方案的详细内容，更多关于MySQL主从复制过滤配置的资料请关注脚本之家其它相关文章！

最新评论