MySQL复制中，通过配置复制过滤规则可以控制从库（Slave）接收并执行哪些数据库或表的更新操作。这在主从架构中实现部分数据同步时非常实用。以下是常见的配置方法和注意事项。
1. 配置基于数据库的复制过滤
使用 replicate-do-db 和 replicate-ignore-db 可以按数据库名称控制复制行为：
replicate-do-db = db_name：只复制指定数据库的操作。 replicate-ignore-db = db_name：忽略指定数据库的所有操作。例如，在从库的 my.cnf 中添加：
[mysqld] replicate-do-db = sales replicate-ignore-db = temp_data
注意：这类规则在使用跨库SQL语句（如
USE other_db; UPDATE sales.table SET ...）时可能不生效，需谨慎使用。
2. 配置基于表的复制过滤
更细粒度的控制可通过表级规则实现：
replicate-do-table = db_name.table_name：仅复制指定表。 replicate-ignore-table = db_name.table_name：跳过指定表的更新。 replicate-wild-do-table：支持通配符匹配表名，如db%.log_*。 replicate-wild-ignore-table：用通配符忽略某些表。
示例配置：
replicate-wild-do-table = app%.user_info replicate-wild-ignore-table = log%.history_*
这类规则适用于需要精确同步特定表的场景，比如只同步用户核心表而跳过日志表。
3. 主库端过滤（不推荐）
可以在主库设置 binlog-do-db 或 binlog-ignore-db 来控制写入二进制日志的内容。但这种方式会影响所有从库，缺乏灵活性，一般建议在从库做过滤。
4. 配置步骤与重启复制
修改配置后需重启复制线程使规则生效：
-
停止从库复制：
STOP SLAVE;修改 my.cnf 文件，添加所需过滤规则。 重启 MySQL 服务或重新启动复制：
START SLAVE;检查状态是否正常：
SHOW SLAVE STATUS\G
确保
Slave_IO_Running和
Slave_SQL_Running均为 Yes，且无错误信息。
5. 注意事项
复制过滤虽然灵活，但也带来一些潜在问题：
跨库操作可能导致意外行为，特别是使用replicate-do-db时。 DDL语句（如 ALTER TABLE）也可能被过滤，导致结构不一致。 一旦启用过滤，备份和恢复策略需特别考虑数据完整性。 多从库环境下，各从库的过滤规则应明确记录，避免运维混淆。
基本上就这些。合理设置复制过滤规则能有效降低从库负载、节省存储空间，但务必测试验证逻辑正确性，避免漏同步关键数据。
