MySQL 8.4 复制过滤为何漏掉目标表：replicate-wild-do-table、库名匹配与配置验收

副本上的 tenant_blue.orders_2026 没有跟上主库，最容易误判成复制线程坏了。MySQL 8.4 里，replicate-wild-do-table 先按库名和表名模式筛选，再结合语句是否明确操作了目标表；模式写宽了、默认库理解错了，或者实际是隐式更新，都会让“看起来匹配”的表被跳过。

先把过滤值、事件中出现的库表名和复制线程当前配置放到同一张核对表里，再决定是改模式还是改复制方式。

先确认漏的是哪一类目标表

假设主库写入了 tenant_blue.orders_2026，副本却没有这条记录。先记录三件事：主库实际库名、实际表名、写入语句里是否带了完整表名。不要只看连接时执行过的 USE tenant_blue，因为这不足以证明表级规则会怎样匹配。

-- 副本：确认复制线程是否仍在应用事件
SHOW REPLICA STATUS\G

-- 副本：确认运行时可见的过滤变量
SHOW VARIABLES LIKE 'replicate%table%';

如果 SQL 线程已经停止，先处理 Last_SQL_Error；如果线程在运行，再进入过滤匹配。两条问题不能混在一起，否则很容易把“线程报错”修成“放宽过滤”。

库名和表名模式要同时匹配

replicate-wild-do-table 接收的是 db_name.tbl_name 模式。比如下面的规则只允许库名以 tenant_ 开头、表名以 orders_ 开头的目标：

[mysqld]
replicate-wild-do-table=tenant_%.orders_%

这里的 % 和 _ 按 LIKE 模式工作。tenant_blue.orders_2026 能匹配，tenant_blue.order_items 不能匹配，archive_blue.orders_2026 也不能匹配。把模式写成 tenant_%.% 会扩大表范围，但不会让库名不匹配的表进入副本。

分清显式表操作和隐式更新

表级过滤只看语句中明确出现并被操作的表。直接执行 UPDATE tenant_blue.orders_2026 SET status = 'paid' 时，目标表名可供规则匹配；但某些只更新系统表、触发器或权限元数据的操作，并不会因为内部最终改动了某张表就自动满足表级模式。

-- 明确提到目标表：可按 tenant_%.orders_% 评估
UPDATE tenant_blue.orders_2026
SET status = 'paid'
WHERE order_id = 9001;

-- 先确认事件中的实际表名，再判断过滤结果
SHOW BINLOG EVENTS IN 'mysql-bin.000021' LIMIT 20;

如果应用使用触发器间接写入另一张表，不要把“主表匹配”当成“所有隐式写入都匹配”。应分别检查事件格式、触发器行为和副本上的应用结果。

运行时配置与启动配置要对得上

如果过滤器通过启动参数写入，检查 mysqld 的启动配置；如果是运行中使用 CHANGE REPLICATION FILTER 设置，检查对应语句和通道。多源复制还要确认过滤器是否绑定到了正确的 channel。

CHANGE REPLICATION FILTER
  REPLICATE_WILD_DO_TABLE = (tenant_%.orders_%);

SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G

不要把命令行配置和运行时配置当成永久等价物。改完后要重新读取副本实际生效的状态，并保存变更时间、通道名和模式值，方便下次故障复盘。

用一条可复现写入完成验收

验收只准备一条边界清楚的写入：一条命中 tenant_%.orders_% 的表，一条只命中库名但不命中表名的表。观察副本是否只出现前者。生产环境不要直接修改真实订单，使用隔离库和可回滚测试数据。

1. 记录主库执行的完整库表名与事务提交位置。
2. 在副本执行 SHOW REPLICA STATUS\G，确认 SQL 线程没有停止。
3. 核对 binlog 中是否显式出现 tenant_blue.orders_2026。
4. 在副本查询命中表和未命中表，分别保存结果。

验收成功的可见状态不是“线程显示 Yes”这一项，而是：SQL 线程持续运行、命中表的写入出现、未命中表没有被误放行，并且过滤值与记录的事件一致。

几个容易把排查带偏的边界

• 模式中的下划线：_ 是单字符通配，不是普通下划线；需要匹配字面量时按手册规则转义。
• 数据库级语句：CREATE DATABASE、DROP DATABASE、ALTER DATABASE 有单独的数据库级过滤判断，不能用表级规则推断。
• 大小写：过滤匹配遵循数据库和表名的大小写规则，还会受 lower_case_table_names 影响。
• 跨库更新：表级规则可以处理跨库更新；不要因为当前默认库不同就直接判定“不匹配”。

相关问题

为什么 replicate-do-db 看起来比 replicate-wild-do-table 更容易误判？

replicate-do-db 的效果会受语句复制格式和当前选中数据库影响；需要精确到跨库表名时，优先按官方规则评估表级过滤。

改了过滤器后要不要立刻重启副本？

取决于采用启动配置还是运行时的 CHANGE REPLICATION FILTER。无论哪种方式，都应重新读取实际配置并用隔离数据做命中与不命中验证。

总结

复制过滤漏表时，排查顺序应固定为“线程状态、实际库表名、模式匹配、显式/隐式更新、配置来源、隔离验收”。只要把 tenant_%.orders_%、tenant_blue.orders_2026 和 binlog 中的真实事件放在一起核对，问题通常会从“复制不稳定”收敛为一个可修正的匹配边界。