replicate_ignore_table没生效是因为必须严格匹配库名和表名的大小写、下划线及格式，且仅对STATEMENT模式binlog有效；ROW模式下需改用replicate_wild_ignore_table或MySQL 8.0+的CHANGE REPLICATION FILTER。
replicate_ignore_table 为什么没生效
MySQL 复制过滤规则中，replicate_ignore_table 看似直接，但实际只在 SQL 线程解析 relay log 时起作用，且**必须严格匹配库名和表名的大小写与下划线**。常见失效原因是：配置写成了 mydb.user_log，但实际表是 mydb.user_log_2024；或主库用小写建库，从库配置了大写库名（尤其在 Windows 主 + Linux 从场景下）。
实操建议：
- 确认表名完全一致：执行
SHOW CREATE TABLE `mydb`.`user_log`查看真实名称，注意反引号包裹和大小写 - 配置格式必须为
replicate_ignore_table = mydb.user_log，不能加引号、不能用通配符、不能跨库写成user_log - 修改后需重启从库或执行
STOP SLAVE; START SLAVE;才会重新加载规则（动态变量不支持该参数） - 验证是否生效：在从库执行
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;，再检查SHOW SLAVE STATUS\G中的Seconds_Behind_Master是否因跳过语句而短暂归零
用 replicate_wild_ignore_table 排除带前缀的业务表
当要忽略一组命名规律的表（如所有 log_ 开头的表），replicate_wild_ignore_table 是更实用的选择。它支持 % 和 _ 通配符，但匹配逻辑是「库名.表名」整体模式，不是单独匹配表名。
常见误用：
-
replicate_wild_ignore_table = %.log_%—— 会匹配otherdb.log_error，但不会匹配mydb.log_user_action，因为%只能代表任意字符，不能跨库跳过 - 正确写法应为
replicate_wild_ignore_table = mydb.log_%，明确指定库名前缀 - 多个规则需分行写，不能用逗号分隔；每行一个规则，重复写多行即可
- 该参数支持热生效：执行
SET GLOBAL replicate_wild_ignore_table = 'mydb.log_%';后，新收到的 relay log 语句立即按新规则过滤
过滤规则和 GTID 模式共存时的限制
开启 gtid_mode = ON 后，MySQL 不允许使用基于库/表名的复制过滤（包括 replicate_ignore_db、replicate_do_table 等），否则启动从库会报错：ERROR 3098 (HY000): The table does not exist... 或直接拒绝启动。
原因在于 GTID 要求事务在所有节点上可重放，而表级过滤会破坏事务原子性——一个事务若同时更新被忽略的表和未被忽略的表，从库无法安全拆分执行。
替代方案只有两个：
- 改用
replicate_do_domain_ids（MySQL 8.0.30+）配合SET GTID_NEXT在主库显式标记事务域，适用极少数跨业务隔离场景 - 在应用层控制：主库写入前判断是否属于业务表，非必要不写；或用中间件（如 Canal、Maxwell）在 binlog 解析阶段过滤，再投递到下游
- 放弃 GTID，切回传统 file:pos 复制（仅限低风险、可控环境）
误删业务表后，如何安全恢复而不破坏复制链路
如果已在从库误执行 DROP TABLE mydb.user_log，且该表本该被 replicate_ignore_table 过滤，此时从库 SQL 线程会卡在找不到表的错误（error_code: 1146），SHOW SLAVE STATUS 显示 SQL thread stopped。
不能直接跳过错误（SET GLOBAL sql_slave_skip_counter = 1），因为后续含该表的 DML 仍会失败，且跳过可能掩盖主从结构不一致问题。
安全做法是：
- 先停复制：
STOP SLAVE; - 确认主库该表结构：
SHOW CREATE TABLE mydb.user_log;，在从库重建同名空表（字段、索引、字符集必须完全一致） - 手动同步缺失数据（如用
mysqldump --no-create-info导出主库数据再导入），或用 pt-table-sync 工具校验 - 重启复制：
START SLAVE;，观察Seconds_Behind_Master是否持续下降 - 关键点：重建表后，原过滤规则依然有效，后续对该表的 INSERT/UPDATE/DELETE 会被正常跳过，不会再次写入
真正容易被忽略的是字符集和存储引擎的一致性——哪怕只是 ENGINE=InnoDB 和 ENGINE=InnoDB ROW_FORMAT=DYNAMIC 的微小差异，也可能导致后续 DDL 失败或主从校验不通过。
