mysql使用复制掩码（Replication Masking）限制复制数据

mysql不支持复制掩码功能，仅提供基于库/表的粗粒度过滤（如replicate-do-table），无法对字段值脱敏或改写；字段级掩码须前置至应用层、中间件或使用企业版脱敏插件（仅影响查询输出）。

MySQL 本身不支持“复制掩码（Replication Masking）”这一功能，也没有名为 Replication Masking 的内置机制或配置项。这是个常见误解，通常源于将其他数据库（如 postgresql 的逻辑复制策略）或第三方工具（如 Debezium、Maxwell）的概念误套到 MySQL 上。

MySQL 的复制过滤能力非常有限，且仅作用于二进制日志事件的分发阶段（即在从库 I/O 线程接收后、SQL 线程执行前），不能对字段值做脱敏、掩码或动态改写。

MySQL 复制中能做什么：基于库/表的黑白名单过滤

MySQL 支持通过以下参数在从库端跳过某些库或表的重放，属于粗粒度过滤：

• replicate-do-db / replicate-ignore-db：按 USE db_name 切换的默认库生效，不推荐使用（行为易混淆，跨库语句可能失效）
• replicate-do-table / replicate-ignore-table：精确到 db_name.table_name，较可靠
• replicate-wild-do-table / replicate-wild-ignore-table：支持通配符，例如 myapp.usr_%，实用性强

这些参数只控制「是否执行」，不修改数据内容。比如你设置了 replicate-ignore-table=finance.credit_card，那整张表的变更都不会应用到从库——但主库上该表的数据依然明文存在、照常写入 binlog。

为什么不能在复制流里做字段级掩码？

MySQL 的复制协议（基于 binlog Event）不提供钩子（hook）或插件接口来拦截、解析、修改单个列值。即使你用 ROW 格式记录变更，Rows_log_event 中的字段值是序列化后的原始字节，没有运行时重写能力。

• binlog 是只读日志，不可篡改；修改它会导致校验失败、复制中断
• MySQL Server 层不暴露列值修改 API 给复制线程
• 官方不提供类似 BEFORE REPLICATION UPDATE 的触发器机制

试图用 UPDATE ... SET card_number = CONCAT('****', SUBSTR(card_number, -4)) 在从库上“补救”，不仅滞后、还破坏主从一致性，属于反模式。

真正可行的替代方案有哪些？

若业务确实需要敏感字段在从库不可见，必须把掩码逻辑前置到应用层或引入中间层：

• 应用写入时脱敏：主库写入前就加密或掩码，例如用 AES_ENCRYPT() 或应用代码处理 card_number，从库自然同步密文
• 专用同步工具：用 Debezium + kafka + KSQL 或 flink CDC 拦截 binlog，对特定字段做 map 转换后再写入目标库
• 视图+权限隔离：从库上建不含敏感字段的视图，并用 GRANT select ON view_name 限制用户访问原始表
• MySQL 8.0+ 数据脱敏插件（仅限企业版）：mysql_secrets 插件可隐藏列值，但仅影响查询输出，不影响复制内容本身

注意：SELECT 层面的脱敏（如 HIDDEN column）不会改变 binlog 内容，从库接收到的仍是原始值。

容易被忽略的关键点

很多团队花时间调试 replicate-* 参数却仍看到不该出现的数据，原因往往是：

• 用了 replicate-ignore-db，但主库语句没带 USE 或用了跨库语法（如 UPDATE user_db.users SET ... FROM finance_db.transactions ...）
• 过滤规则大小写不匹配（linux 下表名区分大小写，mydb.UserTable ≠ mydb.usertable）
• 启用了 GTID 后又手动 SET GLOBAL sql_slave_skip_counter，导致 GTID 不连续、后续复制异常
• 误以为 binlog_format=STATEMENT 可以规避某些过滤，其实反而让 replicate-wild-* 更不可靠

真正安全的字段级控制，只能发生在写入主库之前，或者在复制链路之外的独立消费环节。MySQL 复制本身，就是一条“原样传递”的管道。