17370845950

主库的binlog_do_db和binlog_ignore_db仅在USE匹配且STATEMENT格式下生效，跨库操作失效，MySQL 8.0+已弃用；从库的replicate_do_db等同样依赖USE，行为反直觉；推荐使用replicate_wild_do_table/ignore_table通配符过滤或复制通道实现可靠、灵活的库表级复制控制。

主库用 binlog_do_db 和 binlog_ignore_db 过滤时，从库收不到预期的 binlog

这两个参数只在当前服务器的 USE 数据库匹配时才生效，且基于语句复制（STATEMENT）逻辑，对 INSERT INTO db1.table1 SELECT

* FROM db2.table2 这类跨库操作完全失效。更关键的是：它们作用于主库，但实际复制行为由从库的 SQL 线程解析事件后执行，而主库写入 binlog 时已丢弃被忽略的库操作——导致从库根本收不到任何相关事件，连过滤机会都没有。

实操建议：

• 除非你 100% 使用 STATEMENT 格式 + 每条语句前都显式 USE db_name，否则别碰这两个参数
• MySQL 8.0+ 已将它们标记为 deprecated，未来版本会移除
• 真正可控、可预测的过滤必须放在从库侧

从库用 replicate_do_db 和 replicate_ignore_db 的坑

它们看似直观，但行为反直觉：不是“只复制/忽略某个库”，而是“仅当当前 USE 库匹配时才执行该事件”。这意味着：

• INSERT INTO db1.t1 VALUES (1) 在 USE db2 下执行 → 即使目标表是 db1.t1，也会被跳过
• CREATE TABLE db1.t1 (id INT) 在 USE db1 下执行 → 被复制，但后续往 db1.t1 插数据时若没 USE db1，仍可能被跳过
• 对 mysqldump --databases 导出的多库脚本极不友好，容易漏复制

所以这些参数只适合极简场景（如单库应用 + 严格控制连接默认库），生产环境应避免。

推荐方案：用 replicate_wild_do_table 和 replicate_wild_ignore_table

通配符过滤才是可靠选择，它直接匹配事件中的库名和表名，与当前 USE 无关。例如：

replicate_wild_do_table = app_% .%
replicate_wild_ignore_table = mysql.%

这表示只复制库名以 app_ 开头的所有表，同时明确排除 mysql 系统库所有表。注意语法细节：

• 格式固定为 db_pattern.table_pattern，中间是英文点号，不是下划线或斜杠
• % 匹配任意字符（包括空），_ 匹配单个字符；app\_prod.% 中的反斜杠用于转义下划线字面量
• 多个规则用逗号分隔，但 MySQL 不保证顺序执行，冲突时以“最具体匹配”为准（如 app1.% 和 app%.% 同时存在，app1.t 会命中前者）
• 修改后需重启从库或执行 STOP SLAVE; START SLAVE; 生效，不支持动态 SET

更灵活的替代：使用复制通道（Replication Channels）配合 CHANGE REPLICATION FILTER

MySQL 5.7+ 支持多通道复制，每个通道可独立配置过滤规则。相比全局变量，它允许按用途隔离策略，比如：

CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('app_core.%') FOR CHANNEL 'core_channel';
CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('app_log.%') FOR CHANNEL 'log_channel';

这样两个通道可分别拉取不同业务子集，互不影响。优势在于：

• 规则可在线修改（无需重启），执行 STOP SLAVE FOR CHANNEL 'xxx'; START SLAVE FOR CHANNEL 'xxx'; 即可重载
• 配合 START SLAVE UNTIL 可做灰度同步、临时跳过某段 binlog
• 监控时可通过 performance_schema.replication_applier_status_by_coordinator 查看各通道状态

唯一复杂点是管理成本上升——你需要显式创建通道、指定 MASTER_AUTO_POSITION=1 或手动定位 GTID，且备份恢复时要确保通道配置也被保留。