MySQL 复制过滤规则的风险隔离方法

MySQL 复制过滤的核心不是“让副本少收一点数据”，而是先把副本的用途边界写成一组可审计的允许同步规则，再用一致快照初始化。只做分析查询的副本，可以只接收报表所需的库表；但过滤规则不会替代权限控制，也不会自动修复初始化阶段已经存在的数据。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

更稳妥的顺序是：先按表名建立白名单，再确认二进制日志格式和跨表语句的影响，最后从带复制坐标的一致快照导入副本，确认线程正常后才开放查询。

先把副本要同步的表写成白名单

假设副本只服务订单分析，需要同步 orders、order_items 和维表，不需要同步包含个人资料的 customer_profile。对于这个目标，表级白名单比“同步整个库再排除几张表”更容易审计，因为新增业务表不会悄悄进入副本。

-- 只允许报表库中明确列出的表进入默认复制通道
CHANGE REPLICATION FILTER
  REPLICATE_WILD_DO_TABLE = ('reporting.orders',
                             'reporting.order_items',
                             'reporting.dim_%');

-- 通过 SHOW 语句确认当前通道的过滤状态
SHOW REPLICA STATUS\G

REPLICATE_WILD_DO_TABLE 使用类似 LIKE 的 % 和 _ 通配符，适合把同一类维表纳入白名单。若规则是一次性启动参数，也可以使用 --replicate-wild-do-table。多源复制时，应该把规则绑定到明确的 channel，不要把不同来源的边界混在全局配置里。

不要用数据库过滤替代表级判断

replicate-do-db 看起来直观，但在 statement-based replication 下，它判断的是当前默认数据库，也就是 USE 选中的库；带有显式库名的跨库语句可能和直觉不同。需要精确控制跨库更新时，优先使用 replicate-do-table 或 replicate-wild-do-table。

还要留意三类边界：

• 表级过滤只处理语句中明确操作的表，隐式更新的系统表或对象不一定按表名规则处理。
• 存储过程、函数和事件不是普通表更新，不能只靠一个表级规则覆盖。
• statement-based 事件必须整体执行或整体忽略；同一语句同时触碰允许表和排除表时，可能无法安全拆分。row-based 对 DML 更容易按行所属表处理，但 DDL 仍要按语句边界谨慎评估。

因此，规则变更前要先列出会跨表写入的 SQL 类型。不要把“副本没有报错”当成“副本数据完整”的证明；过滤本来就会让一部分事件被忽略。

初始化必须和复制坐标来自同一个快照

过滤只影响复制线程处理到的事件，不能清理副本已有的敏感表，也不能弥补一个时间点不一致的导入。已有数据的副本应先从源库制作快照，再在副本上导入，随后使用快照对应的复制坐标配置来源。

# InnoDB 场景下使用带来源坐标的快照；文件内容由源库生成
mysqldump --all-databases --source-data > fulldb.dump

# 先禁止副本启动复制线程，再导入快照
mysqld --skip-replica-start
mysql 

生产环境不要照抄示例中的主机、账号和坐标。使用 GTID 时，还要特别审视部分库表导出对 gtid_purged 的影响：快照可能包含源端已经执行过、但没有导出的其它事务集合，部分导出前应先按当前环境的 GTID 策略确认处理方式。

用检查清单把风险关在变更前

过滤规则上线前，可以把检查拆成四个互相独立的结果：

如果发现过滤范围设计错了，优先停止副本 SQL 线程、保留错误和规则变更记录，再从一份新的正确快照重建。直接在已有脏副本上补几条过滤规则，只会让“历史数据”和“后续事件”遵循不同的边界，排查成本更高。

相关问题

复制过滤能否代替权限隔离？

不能。过滤决定哪些复制事件被应用，账号权限决定谁能读取副本；两者必须同时设计。

为什么新增表没有出现在副本？

白名单规则只允许匹配的表进入副本。新增表需要先评估用途，再显式修改过滤规则，并按一致性方案补齐初始化数据。