replicate_ignore_table仅在STATEMENT或MIXED binlog格式下生效，ROW格式下被忽略；GTID模式下所有replicate_*_table参数均失效，需改用sql_slave_skip_counter（先设GTID_NEXT='ANONYMOUS'）或主库binlog_ignore_db控制。
MySQL 主从复制中 replicate_ignore_table 不生效？先确认 binlog 格式
逻辑备库跳过特定表，最常用的是 replicate_ignore_table，但它只在 statement 或 mixed binlog 格式下有效；如果主库用了 row 格式，这个参数直接被忽略——这是绝大多数人踩坑的起点。
实操建议：
- 查主库：
SHOW VARIABLES LIKE 'binlog_format';，确认不是ROW - 若已是
ROW，别硬改replicate_ignore_table，它不会起作用 - 临时切格式需重启 MySQL，且可能影响已有业务，不推荐在线切换
用 replicate_wild_ignore_table 替代时通配符怎么写才安全
replicate_wild_ignore_table 支持 % 和 _，但容易因过度匹配误伤其他表。比如想跳过 test.log_2023，写成 test.log_% 没问题；但写成 %log% 可能连 user_login_log 也跳过了。
实操建议：
- 优先用具体库名前缀：
myapp.tmp_%、monitoring.metrics_2024% - 避免开头用
%，除非你真要跨库过滤（这时更要核对所有库名） - 多个表用多个配置项，不要拼成一个带逗号的字符串——MySQL 不支持
- 配置后必须重启 IO 线程：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;，否则不加载新规则
GTID 模式下 replicate_*_table 全部失效，只能靠 sql_slave_skip_counter 或过滤器
开启 GTID（gtid_mode=ON）后，所有基于表名的复制过滤参数（replicate_do_table、replicate_ignore_table 等）都会被 MySQL 忽略。这是设计使然，不是 bug。
实操建议：
- GTID 环境下唯一可靠方式是：在备库执行
SET GLOBAL sql_slave_skip_counter = 1;跳过当前事务（仅限临时应急） - 长期方案是改用
replicate_rewrite_db配合库级过滤，或更彻底地——在主库用binlog_ignore_db控制源头不记录 - 注意：
sql_slave_skip_counter在 GTID 下会报错，必须先SET SESSION GTID_NEXT='ANONYMOUS'再设计数器
过滤规则写进 my.cnf 后没生效？检查配置加载顺序和权限
很多同学把 replicate_wild_ignore_table 加到 [mysqld] 段就以为完事了，结果发现还是同步。常见原因是配置没被读取，或者被后续配置覆盖。
实操建议：
- 确认 MySQL 启动时实际加载的配置文件：
mysqld --verbose --help | grep "Default options" - 检查是否有多个
[mysqld]段，后面段会覆盖前面同名参数 - 确认配置文件权限为 MySQL 用户可读（
chown mysql:mysql /etc/my.cnf） - 修改后必须重启 MySQL（不是
RELOAD），因为这类参数是启动时读取的
真正麻烦的从来不是写哪条规则，而是你不确定当前复制链路到底在哪个环节做过滤——主库 binlog 生成、网络传输、备库 SQL 线程解析，每个环节的过滤机制都不同，且互不兼容。
