MySQL 复制过滤怎样确认表规则已加载

确认 MySQL 复制表过滤规则已加载，应连接目标副本，查看指定通道的 SHOW REPLICA STATUS，再查询 performance_schema.replication_applier_filters 中的 FILTER_NAME 与 FILTER_RULE。需要追溯全局配置时，再读 replication_applier_global_filters。配置文件里有规则，只说明文件内容存在；运行时规则表才能说明当前实例配置了什么。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/performance-schema-replication-applier-filters-table.html

把实例和通道作为规则的归属键

以下按 MySQL 8.4 的普通异步复制环境说明。假设运维记录要求 sales_feed 通道排除 sales_stage.import_buffer，这只是本次原创示例，不是真实配置或执行结果。先确定目标副本和通道，再讨论规则值，避免在源实例、代理后的其他实例或另一个通道上得出结论。

-- 先确认查询的是目标副本，记录版本和实例身份。
SELECT @@server_uuid AS replica_uuid, @@hostname AS host_name,
       @@port AS port_number, VERSION() AS mysql_version;
-- sales_feed 是示例命名通道，替换为实际通道；默认通道使用空字符串。
SHOW REPLICA STATUS FOR CHANNEL 'sales_feed';

在状态结果中查看 Channel_Name，以及 Replicate_Do_Table、Replicate_Ignore_Table、Replicate_Wild_Do_Table、Replicate_Wild_Ignore_Table。精确表规则和通配表规则应分别读，不要看到一个字段为空就判断所有表规则都没加载。默认通道名称为空字符串，与名为 sales_feed 的通道不同。

读取内存中的通道规则

-- 读取该通道的全部过滤类型，避免只看一条表规则漏掉其他限制。
SELECT CHANNEL_NAME, FILTER_NAME, FILTER_RULE,
       CONFIGURED_BY, ACTIVE_SINCE, COUNTER
FROM performance_schema.replication_applier_filters
WHERE CHANNEL_NAME = 'sales_feed'
ORDER BY FILTER_NAME;

CHANNEL_NAME 指明通道，FILTER_NAME 指明过滤类型，FILTER_RULE 保存该类型配置的规则。对应精确排除表的类型是 REPLICATE_IGNORE_TABLE，通配排除表则是 REPLICATE_WILD_IGNORE_TABLE。将查询结果里的规则集合与变更单逐项比较；若包含多项，不应只靠原始字符串顺序判断是否一致。

在示例场景中，只有目标通道下的相应类型确实包含 sales_stage.import_buffer，才足以记录“该通道的运行时表规则已配置”。这里不提供伪造的结果表，也不把示例期待值描述成已经加载的事实。

把全局规则和通道规则分开保存

-- 全局过滤没有 CHANNEL_NAME，不能套用通道表的查询字段。
SELECT FILTER_NAME, FILTER_RULE, CONFIGURED_BY, ACTIVE_SINCE
FROM performance_schema.replication_applier_global_filters
ORDER BY FILTER_NAME;

全局过滤表记录副本上的全局配置，通道表记录各通道的配置。全局配置与通道专用配置可能有不同来源和覆盖关系，不能把两张表的文本简单拼接成最终规则。确认某一通道时，应以该通道的运行时记录为直接观察对象，再用全局记录解释来源。

通道表的 CONFIGURED_BY 区分启动选项、动态语句，以及带通道范围的配置方式；ACTIVE_SINCE 是配置时间。它不是某一业务事务首次受过滤的时间，也不是配置文件修改时间。COUNTER 记录过滤器配置后被使用的次数，不能当成“丢弃了多少行”的统计，更不能靠零值证明规则未加载。

排查差异时，先区分缺失、范围与持久性

CHANGE REPLICATION FILTER 的动态变更不跨 mysqld 重启持久保存；需要长期保留时，应把预期规则纳入实际部署使用的启动配置管理。本文只读加载状态，不执行停复制、改过滤或重启命令。仅为了确认加载就改变复制范围，可能把排障变成新的数据差异。

查询报权限错误，应记录错误并使用获准的诊断账号；它与查询成功但没有记录是两种情况。状态查询没有返回目标通道时，也应先确认通道是否存在，不能把“查错通道”归结为“过滤语法无效”。

归档结论，保留后续效果判断的边界

一次完整记录应包含副本 UUID、版本、通道名、过滤类型、规则集合、CONFIGURED_BY、ACTIVE_SINCE 和采样时间。保留变更前后两份记录及配置版本，替换或删除规则时仍能解释差异；不要在分享排障材料时夹带复制连接密码或其他凭据。

“已加载”只说明当前配置存在。真实事务是否被排除，还与过滤优先级、事件内容以及行格式或语句格式有关；不能从规则文本单独推出所有跨库操作的结果。实际过滤效果需要另行结合既有复制事件和数据证据判断，不应在生产中随意写入测试业务数据。

复制线程运行就表示规则正确吗？

不能。线程状态说明运行情况，不代表表名、通道和规则范围符合变更目标。

过滤器会清理已经复制过去的旧行吗？

不能把复制过滤当成历史数据清理方案。确认规则存在，不代表既有副本数据已经被删除或修复。

技术依据：通道过滤记录、全局过滤记录、复制状态字段、动态过滤配置说明。