replicate-do-db必须配置在从库my.cnf的[mysqld]段并重启MySQL进程才生效，它依赖USE语句或显式库名前缀匹配，不检查SQL实际操作的库，跨库操作易失效；更可靠的替代方案是replicate-wild-do-table，按表名通配匹配且不受USE影响。
replicate-do-db 配置必须写在从库的 my.cnf 里
这个参数只在从库生效，主库上配了也没用。它不是运行时动态参数，必须在从库启动前写入配置文件，否则启动后修改再 SET GLOBAL 是无效的。很多同学试过改完 reload 或 restart mysqld 却没效果，就是因为没重启整个 MySQL 进程（仅 reload config 不触发复制过滤重载）。
常见错误现象：SHOW SLAVE STATUS\G 中 Replicate_Do_DB 字段为空，或同步了不该同步的库（比如 mysql 系统库），基本就是配置没生效或没重启。
- 配置位置：必须在从库的
/etc/my.cnf或/etc/mysql/my.cnf的[mysqld]段下 - 语法：每行一个
replicate-do-db = db_name，支持多行，不支持逗号分隔 - 重启要求：改完必须执行
systemctl restart mysql（或对应服务名），不能只mysqladmin reload
replicate-do-db 匹配逻辑依赖 USE 语句或显式库名前缀
它不是按 SQL 执行时实际影响的库来判断，而是看语句是否“属于”该库——即是否在 USE app_db 后执行，或语句中写了 app_db.table_name。如果直接执行 INSERT INTO users（没 USE、也没库名前缀），哪怕表在 app_db 里，这条语句也不会被匹配。
这意味着：跨库操作（如 INSERT INTO order_db.orders SELECT * FROM app_db.users）可能被漏掉或误同步，取决于哪边用了前缀、哪边用了 USE。
- 安全做法：所有业务 SQL 显式带上库名前缀，避免依赖
USE - 慎用混搭：不要和
replicate-ignore-db同时配置，两者规则冲突时行为不可靠 - 验证方式：在主库执行
USE app_db; INSERT INTO t1 ...，再查从库是否同步；再试INSERT INTO app_db.t1 ...，确认都生效
replicate-wild-do-table 更可靠，尤其用于按表过滤
当你要同步 app_db 下的 users 和 orders 表，但不想同步 app_db.log_2025 这类历史表，replicate-do-db 就力不从心了——它只能控制库级，没法筛表。这时候 replicate-wild-do-table 是更优解。
它用通配符匹配 db_name.table_pattern，不依赖 USE，只要语句里出现匹配的库表组合就生效，包括 JOIN、子查询、跨库引用等复杂场景。
- 示例：
replicate-wild-do-table = app_db.users（精确匹配）、replicate-wild-do-table = app_db.order%（匹配order开头的所有表） - 注意：
%匹配任意字符（含零个），_匹配单个字符，不支持正则 - 优先级：多个
replicate-wild-do-table规则是“任一匹配即同步”，不是“全匹配”，所以白名单思维更稳
配置后必须重置复制位点才能生效
即使你正确配置并重启了从库，已有的复制关系不会自动应用新规则。MySQL 会继续按旧的 relay log 位置执行，而旧日志里可能包含已被过滤掉的库/表操作，导致从库数据错乱或报错。
正确做法是：停复制 → 清空 relay log → 重设 master position（通常用 CHANGE MASTER TO ... MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy）→ 再启动复制。这一步常被跳过，结果就是“配置写了，但没起作用”。
- 关键命令：
STOP SLAVE;→RESET SLAVE;（清 relay log + info）→CHANGE MASTER TO ...→START SLAVE; - 位点来源：需从主库
SHOW MASTER STATUS获取最新File和Position，不能沿用旧值 - 风险提示：重置前确保主从数据一致，或已做好备份；否则可能丢数据
实际线上环境里，replicate-do-db 看似简单，但真正跑稳需要同时踩对配置位置、重启动作、SQL 编写习惯、复制重置四步。最容易被忽略的是最后一步——很多人以为改完配置重启 mysqld 就万事大吉，结果同步还在跑老日志。
