最稳妥方式是在从库配置 replicate-do-db 或 replicate-ignore-db；需重启 MySQL 或 SQL 线程生效，且仅 SQL 线程过滤，IO 线程仍拉取全部 binlog。
在 MySQL 主从复制中，过滤特定数据库最稳妥的方式是在从库端配置库级白名单或黑名单，而不是动主库的 binlog-do-db —— 后者会破坏 binlog 完整性，影响灾备恢复，且受 USE 语句上下文限制，容易漏同步。
用 replicate-do-db 实现库级白名单
这是从库只同步指定库的标准做法，适合“只保留几个核心库”的场景：
- 在从库的 my.cnf 的 [mysqld] 段下添加：
replicate-do-db = db1<br>replicate-do-db = db2
- 每行一个库名，不支持逗号分隔；大小写敏感，取决于从库
lower_case_table_names设置 - 该规则只对当前 USE 的库生效 —— 执行
INSERT INTO db2.t1 ...但没先USE db2，这条语句可能被跳过 - 若需跨库语句（如
UPDATE db1.a JOIN db2.b）也可靠同步，建议改用replicate-wild-do-table配合通配符
用 replicate-ignore-db 实现库级黑名单
适合“默认全量同步，仅排除几个非关键库”的轻量需求：
- 配置示例：
replicate-ignore-db = mysql<br>replicate-ignore-db = performance_schema<br>replicate-ignore-db = test
- 同样每行一个库，大小写敏感
- 注意：
replicate-ignore-table依赖replicate-ignore-db生效 —— 如果想忽略test.log_2025，必须同时配置这两项 - ROW 格式 binlog 下，
replicate-ignore-db仍有效，但判断依据是语句涉及的表所属库，不是 USE 上下文，更稳定
必须执行的后续操作
配置完不能只执行 START SLAVE，否则规则不加载：
- 修改 my.cnf 后，必须重启 MySQL 进程：
systemctl restart mysqld - 或至少重启 SQL 线程：
STOP SLAVE SQL_THREAD; START SLAVE SQL_THREAD; - 验证是否生效：
SHOW VARIABLES LIKE 'replicate%';查看Replicate_Do_DB或Replicate_Ignore_DB是否有值；再运行SHOW SLAVE STATUS\G，确认Seconds_Behind_Master正常、无报错 - 注意：IO 线程始终拉取全部 binlog，SQL 线程才做过滤。所以从库磁盘和网络开销不会减少，只是本地不应用
为什么不推荐在主库设 binlog-do-db？
看似省带宽，实则埋雷：
- 主库 binlog 不完整 → 无法用于全量恢复或搭建新从库
-
binlog-do-db只记录 USE 当前库后的语句 →INSERT INTO db2.t1 ...在USE db1下执行，会被丢弃 - 所有从库被迫统一同步范围，丧失灵活性
- MySQL 8.0.26+ 已明确标记部分库级过滤参数为废弃，官方倾向表级通配符方案
