replicate-do-db 和 replicate-ignore-db 在从库配置可行但不可靠：仅对 use 当前库后的语句生效，跨库操作易漏同步；row 模式下 replicate-do-db 按事件所属库名匹配，非 use 上下文；二者不可混用，否则行为未定义；必须重启 mysqld 生效，且不清理历史数据。
直接说结论：在从库配置 replicate-do-db 或 replicate-ignore-db 是可行的，但必须清楚它们只对 USE 当前库后执行的语句生效，且容易因跨库操作漏同步——不推荐单独依赖它做核心过滤。
replicate-do-db 在 ROW 模式下到底匹配什么
MySQL 5.7.6+、特别是 8.0 默认用 binlog-format = ROW，这时 replicate-do-db 的行为和很多人想的不一样：它不再看 SQL 里有没有 USE db_name，而是看变更的那条记录所属的库名（即 binlog event 中的 db_name 字段）。
- 比如主库执行
INSERT INTO app_db.users VALUES (1,'a');，即使没USE app_db，只要这条记录属于app_db库，replicate-do-db = app_db就能命中 - 但若主库执行
USE log_db; INSERT INTO app_db.orders ...，这个 event 的db_name是log_db，replicate-do-db = app_db就会跳过——这是常见误同步点 - 所以它“相对可靠”仅限于单库事务、无跨库写入的场景
replicate-ignore-db 和 replicate-do-db 能混用吗
不能。MySQL 官方文档明确警告：这两个参数逻辑冲突，优先级不透明，行为不可预测。实际测试中，一旦同时存在，往往 replicate-ignore-db 会覆盖或干扰 replicate-do-db 的判断，导致本该同步的库也被跳过。
- 例如配置了
replicate-do-db = app_db和replicate-ignore-db = mysql，看似合理，但某次app_db里的触发器调用了mysql.proc，整个事务可能被整条丢弃 - 真正需要“白名单 + 黑名单”组合的场景，应该改用
replicate-wild-do-table配合replicate-wild-ignore-table - 如果非要用库级控制，只保留
replicate-do-db多行声明，其余库默认不复制
配置后为什么 SHOW SLAVE STATUS 看不到效果
因为这些参数是 mysqld 启动时加载的静态配置，修改 my.cnf 后不重启服务或不重置复制线程，SQL 线程根本不会重新读取规则。
- 必须先执行
STOP SLAVE;，再重启 MySQL 进程（systemctl restart mysqld），而不是只START SLAVE; - 重启后检查是否加载成功：
SHOW VARIABLES LIKE 'replicate%';，确认replicate_do_db值非空且内容正确 - 再执行
START SLAVE;，然后立刻查SHOW SLAVE STATUS\G，重点看Seconds_Behind_Master是否开始下降，以及Replicate_Wild_Do_Table字段是否为空（若为空说明没用通配符规则，但不影响库级） - 如果状态里出现
Could not execute Write_rows_v1 event on table ...类错误，大概率是过滤后从库缺表结构，需手动CREATE DATABASE或CREATE TABLE
最常被忽略的一点：过滤规则只控制“后续同步”，不会自动删掉从库上已存在的、本不该同步的库或表。上线前务必人工清理，否则业务连错库都查不到问题根源。
