MySQL主从复制过滤配置详解与实践

1. MySQL主从复制过滤配置概述

在企业级数据库架构中，MySQL主从复制是最基础也是最核心的高可用方案之一。但实际生产环境中，我们常常遇到这样的需求：主库上有数十个业务库，而从库只需要同步其中几个关键库；或者某些敏感表不希望同步到从库。这时候就需要用到复制过滤功能。

主从复制过滤主要分为两种实现方式：

• 主库端过滤：通过binlog_do_db和binlog_ignore_db参数控制
• 从库端过滤：通过replicate_do_db、replicate_ignore_db等参数控制

这两种方式各有优劣：

• 主库端过滤能减少网络传输和磁盘I/O
• 从库端过滤更灵活，可以针对不同从库设置不同过滤规则

2. 主库端过滤配置详解

2.1 配置参数说明

在主库的my.cnf配置文件中，可以添加以下参数：

[mysqld] # 只同步指定的数据库 binlog_do_db=database1 binlog_do_db=database2 # 忽略指定的数据库 binlog_ignore_db=database3

注意：binlog_do_db和binlog_ignore_db不能同时使用，否则会出现不可预期的行为

2.2 配置示例与验证

假设我们有以下需求：

• 主库上有db1、db2、db3三个数据库
• 只希望同步db1和db2到从库

配置步骤：

1. 编辑主库my.cnf文件：

[mysqld] binlog_do_db=db1 binlog_do_db=db2

2. 重启MySQL服务使配置生效

3. 验证配置：

SHOW VARIABLES LIKE 'binlog_do_db';

2.3 主库过滤的优缺点

优点：

• 减少网络传输量
• 降低从库I/O压力
• 节省存储空间

缺点：

• 不够灵活，所有从库必须同步相同的库
• 一旦配置错误可能导致数据不一致
• 切换主从角色时需要重新配置

3. 从库端过滤配置详解

3.1 常用过滤参数

从库端提供了更丰富的过滤选项：

[mysqld] # 数据库级过滤 replicate_do_db=db1 replicate_ignore_db=db2 # 表级过滤 replicate_do_table=db1.t1 replicate_ignore_table=db2.t2 # 通配符过滤 replicate_wild_do_table=db3.% replicate_wild_ignore_table=db4.backup_%

3.2 多从库差异化配置实战

假设我们有一个主库和两个从库：

• 主库有order、user、log、report四个库
• 从库1只需要同步order和user库
• 从库2只需要同步report库

配置步骤：

1. 从库1的my.cnf配置：

[mysqld] replicate_do_db=order replicate_do_db=user

2. 从库2的my.cnf配置：

[mysqld] replicate_do_db=report

3. 分别重启两个从库的MySQL服务

4. 验证过滤效果：

-- 在主库上操作 CREATE DATABASE temp; USE order; CREATE TABLE t1(id INT); USE report; CREATE TABLE t2(id INT); -- 在从库1上检查 SHOW DATABASES; -- 应该只有order和user SHOW TABLES FROM order; -- 应该有t1 -- 在从库2上检查 SHOW DATABASES; -- 应该只有report SHOW TABLES FROM report; -- 应该有t2

3.3 从库过滤的注意事项

1. 过滤规则是叠加生效的，配置时要考虑优先级
2. 通配符规则要谨慎使用，避免意外过滤
3. 修改过滤规则后需要重启复制线程
4. 可以使用SHOW SLAVE STATUS查看过滤是否生效

4. 表级过滤的进阶应用

4.1 精确控制表同步

在某些场景下，我们需要更细粒度的控制：

[mysqld] # 只同步user库的info表 replicate_do_table=user.info # 忽略order库的temp表 replicate_ignore_table=order.temp

4.2 通配符的高级用法

[mysqld] # 同步所有以"prod_"开头的表 replicate_wild_do_table=%.prod_% # 忽略所有备份表 replicate_wild_ignore_table=%.bak_%

4.3 表过滤的实际案例

电商系统常见需求：

• 主库：order, user, product, log等库
• 从库1(用于报表)：只需要order和product库，但不需要order库中的cart临时表
• 从库2(用于分析)：只需要user库中的基础信息表

配置示例：

从库1的my.cnf:

[mysqld] replicate_do_db=order replicate_do_db=product replicate_ignore_table=order.cart

从库2的my.cnf:

[mysqld] replicate_do_table=user.basic_info replicate_do_table=user.address

5. 过滤配置的监控与维护

5.1 监控过滤效果

-- 查看正在生效的过滤规则 SHOW SLAVE STATUS\G -- 检查是否有被过滤的事件 SELECT * FROM performance_schema.replication_applier_filters;

5.2 动态修改过滤规则

从MySQL 5.7开始，支持动态修改部分过滤参数：

-- 动态添加过滤规则 CHANGE REPLICATION FILTER REPLICATE_DO_DB = (db1); -- 动态移除过滤规则 CHANGE REPLICATION FILTER REPLICATE_DO_DB = ();

注意：动态修改后需要重启复制线程才能生效

5.3 常见问题排查

1. 过滤不生效：

• 检查参数拼写是否正确
• 确认是否重启了MySQL服务或复制线程
• 检查是否有冲突的过滤规则

2. 意外过滤了数据：

• 检查通配符是否匹配了不该匹配的表
• 确认过滤规则的优先级

3. 复制延迟增大：

• 检查是否过滤规则过于复杂
• 确认从库性能是否足够

6. 生产环境最佳实践

6.1 配置建议

1. 尽量使用从库端过滤，保持灵活性
2. 为每个从库明确记录过滤规则
3. 重要从库建议不做过滤或少做过滤
4. 测试环境配置与生产环境保持一致

6.2 变更管理流程

1. 修改前在测试环境验证
2. 变更时记录当前复制位置
3. 逐个从库进行配置变更
4. 变更后验证数据一致性

6.3 高可用考量

1. 主库切换后要重新检查过滤配置
2. 考虑使用GTID简化过滤配置管理
3. 重要从库建议配置为可提升为主库

7. 性能影响与优化

7.1 过滤对性能的影响

1. 主库端过滤：

• 减少binlog写入量
• 降低网络传输
• 减少从库I/O

2. 从库端过滤：

• SQL线程需要解析和过滤事件
• 复杂规则可能增加CPU开销
• 可能造成复制延迟

7.2 优化建议

1. 简化过滤规则
2. 避免使用过多通配符
3. 定期检查过滤效果
4. 考虑使用多层级复制架构

8. 与其他特性的配合使用

8.1 与GTID复制结合

GTID复制下使用过滤需要注意：

1. 过滤不会改变GTID编号
2. 切换主从时需要特别小心
3. 建议使用从库端过滤

8.2 与半同步复制结合

半同步复制下：

1. 主库端过滤可能导致确认机制异常
2. 从库端过滤不影响半同步行为
3. 建议测试确认后再上线

9. 实际案例分享

某金融系统配置案例：

• 主库包含：交易库、客户库、风控库、日志库
• 同城灾备从库：全量同步
• 异地报表从库：只同步交易库和客户库
• 测试环境从库：只同步部分表结构

配置要点：

1. 使用从库端过滤实现差异化同步
2. 为每个从库建立详细的过滤文档
3. 定期检查各从库的数据一致性
4. 主库切换演练时特别注意过滤配置

10. 总结与个人建议

MySQL主从复制过滤是一个强大但需要谨慎使用的功能。根据我的经验：

1. 对于小型系统，建议使用从库端过滤，配置简单灵活
2. 对于大型系统，可以考虑主库端过滤减少I/O压力
3. 表级过滤要特别注意通配符的使用
4. 任何过滤配置变更都要先在测试环境验证

最后提醒：过滤配置一旦出错可能导致数据不一致，建议配合定期数据校验机制使用。