配置 MySQL 主从复制过滤特定数据库同步，推荐在从库配置文件 my.cnf 中设置 replicate-do-db 或 replicate-wild-do-table 参数。该方案适合需要减少从库存储压力或隔离非业务数据的场景，但需注意 binlog_format 为 ROW 时部分库级过滤参数可能失效。
先说结论：从库配置过滤规则是安全且灵活的标准做法，主库过滤会导致 binlog 不完整。
- 适合：多租户架构、数据隔离或特定业务场景，需减少从库磁盘空间和网络传输压力。
- 先准备：确认从库 MySQL 版本及 binlog_format 格式，ROW 格式下优先使用表级通配符过滤。
- 验收：修改配置后重启从库服务，通过 SHOW SLAVE STATUS 确认过滤规则已加载且无同步延迟。
命令速用版
[mysqld]
replicate-do-db = app_db
replicate-wild-do-table = order_db.order_%
保存后执行 systemctl restart mysqld 重启服务。
为什么会这样
主库过滤会限制 binlog 完整性，从库过滤允许不同从库同步不同数据。主库设置 binlog-do-db 会导致所有从库只能同步指定库，且 binlog 不完整无法用于全量恢复；从库设置 replicate-do-db 仅影响本地 SQL 线程应用，主库 binlog 保持完整，支持灵活扩展。
分步处理
1. 编辑从库配置文件 my.cnf 或 my.ini，在 [mysqld] 段添加过滤参数。
2. 停止从库复制线程：STOP SLAVE;。
3. 重启 MySQL 服务使配置生效：systemctl restart mysqld。
4. 启动复制线程：START SLAVE;。
5. 检查状态：SHOW SLAVE STATUS\G。
怎么验证是否生效
执行 SHOW SLAVE STATUS\G，查看 Replicate_Do_DB 或 Replicate_Wild_Do_Table 字段是否显示配置的规则。在主库对目标库和非目标库分别写入数据，观察从库是否仅同步了目标库数据。
常见坑
1. 动态设置无效：replicate-ignore-table 等参数不支持 SET GLOBAL 动态修改，必须写配置文件并重启。
2. ROW 格式限制：binlog_format 为 ROW 时，replicate-ignore-db 基于库名的过滤可能失效，建议改用 replicate-wild-ignore-table。
3. 历史数据残留：过滤规则仅对新事件生效，不会自动删除从库已同步的非目标数据，需手动清理。
4. 跨库语句风险：基于库名的过滤依赖 USE 数据库上下文，跨库操作可能导致意外过滤或同步。
常见问题
能否在不重启 MySQL 的情况下生效过滤规则？
不能。复制过滤参数属于只读变量，修改 my.cnf 后必须重启 MySQL 进程或重置复制链路才能加载新规则。
过滤配置会自动删除从库已存在的非同步表吗？
不会。过滤规则只拦截新同步的事件，已存在于从库的非目标表数据需手动执行 DROP TABLE 清理。
主库需要配合修改配置吗？
不需要。主库只需开启 binlog 并允许从库连接，过滤逻辑完全由从库自主控制，主库无需特殊设置。
参考来源
- 数据库主从复制过滤：如何只同步关键业务数据
- mysql 主从复制如何只同步部分库_mysql 复制过滤配置
- 3、主从复制实现同步数据过滤
- 如何设置主从同步时忽略特定的表_复制过滤规则排查
- mysql 通过复制排除数据库与表的同步