MySQL复制过滤应在从库配置，优先使用replicate-wild-do-table做表级白名单，匹配「库名.表名」全路径；慎用replicate-do-db，避免主库binlog裁剪；配置后需重启mysqld生效。
MySQL 复制过滤的核心目标是让从库只同步真正需要的数据，避免日志表、测试库或敏感数据占用资源。关键在于：所有可靠过滤都应在从库配置，且必须明确区分“白名单”与“黑名单”逻辑，同时严格适配 binlog 格式。
优先用 replicate-wild-do-table 做表级白名单
这是当前生产环境最稳定的方式，不依赖 USE 语句，对 STATEMENT 和 ROW 格式均有效，匹配规则为「库名.表名」全路径：
- 写法示例：
replicate-wild-do-table = db1.user_%—— 匹配db1.users、db1.user_log_2025，但不匹配db1.log_events - 下划线
_是单字符通配符，如需匹配log_202506，必须转义：db1.log\_% - 多个规则每行一条，不能逗号分隔；大小写敏感，取决于从库
lower_case_table_names设置 - 若同时配置了
replicate-do-db，它会先判断库是否命中——未命中则直接跳过表级规则，所以纯表级控制时建议清空所有库级参数
慎用 replicate-ignore-table，推荐改用 replicate-wild-ignore-table
replicate-ignore-table 只在 STATEMENT/MIXED 格式下生效，主库若设为 ROW 格式，该参数完全失效：
- 必须写全名（如
app.log_events），且大小写敏感 -
replicate-wild-ignore-table = app.log%更灵活，支持通配符，同样兼容 ROW 格式 - 配置后不会自动删除从库已存在的对应表；若该表此前已同步，需手动
DROP TABLE，否则后续TRUNCATE或DROP会报错 - 该变量只读，
SET GLOBAL replicate_ignore_table = '...'无效，不支持运行时修改
避免在主库用 binlog-do-db 或 binlog-ignore-db
这类参数作用于 binlog 生成阶段，不是复制过滤，而是日志裁剪：
- 启用后，被排除的库操作根本不会写入 binlog，导致 GTID 集合不一致、新从库无法追平、
mysqlbinlog --database=xxx查不到事件 - 尤其在 GTID 模式下，
RESET MASTER可能引发 GTID 错位，造成复制中断 - 主库应保持 binlog 完整性，过滤逻辑全部下放到从库执行
配置生效必须重启 SQL 线程或 mysqld 进程
修改 my.cnf 后仅执行 START SLAVE 不足以加载新规则：
-
STOP SLAVE; START SLAVE;只重启 SQL 线程，IO 线程仍按旧规则拉取 relay log，可能积压或误同步 - 正确做法：先
STOP SLAVE SQL_THREAD，再重启整个 MySQL 进程（systemctl restart mysqld） - MySQL 8.0.22+ 支持
SET PERSIST，但replicate-wild-do-table仍需重启，不支持热加载 - 验证方式：
SHOW VARIABLES LIKE 'replicate%'查值是否更新；SHOW SLAVE STATUS\G确认Replicate_Wild_Do_Table非空
