MySQL 主从架构迁移新机房时，调整 replicate_do_db 需要在从库停止 SQL 线程后通过 CHANGE REPLICATION FILTER 命令动态修改，或修改配置文件后重启服务。主要风险是过滤规则设置不当会导致从库数据缺失，影响业务一致性。

命令速用版

STOP SLAVE;
CHANGE REPLICATION FILTER REPLICATE_DO_DB = (db1, db2);
START SLAVE;
SHOW SLAVE STATUS\G

为什么会这样

replicate_do_db 的过滤机制依赖于 SQL 语句中的 USE 命令，而非实际更新的表所属库。

如果在主库执行跨库更新（例如 USE db1; UPDATE db2.table...），从库即使配置了 replicate_do_db = db2 也不会同步该操作。迁移新机房时若网络带宽受限或只需部分数据，调整此配置可减少同步量，但必须理解其过滤边界，否则会导致从库数据不完整。

分步处理

1. 确认版本支持：检查 MySQL 版本是否支持 CHANGE REPLICATION FILTER 动态命令，5.7 之前通常需重启。

2. 停止复制线程：执行 STOP SLAVE; 停止 SQL 线程，避免配置变更期间写入冲突。

3. 修改过滤规则：使用 CHANGE REPLICATION FILTER 设置新的数据库列表，或使用 my.cnf 配置后重启。

4. 启动复制线程：执行 START SLAVE; 恢复同步。

5. 回滚准备：若发现数据缺失，立即停止同步，重新全量初始化从库。

怎么验证是否生效

执行 SHOW SLAVE STATUS\G 查看 Slave_IO_Running 和 Slave_SQL_Running 是否为 Yes。

观察 Seconds_Behind_Master 是否逐渐归零，并在主库创建测试表验证从库是否按预期同步或过滤。

常见坑

1. 跨库更新失效：binlog_format 为 STATEMENT 时，跨库更新极易因过滤规则丢失数据，建议迁移期间使用 ROW 格式。

2. 临时表同步：某些版本的 MySQL 对临时表的复制过滤行为不一致，需测试验证。

3. 配置持久化：动态命令修改仅生效于当前运行期，重启从库后会失效，需同步修改配置文件。

常见问题

修改 replicate_do_db 需要重启从库吗？

MySQL 5.7 及以上版本支持在线动态修改，无需重启；5.6 及更早版本通常需要修改配置文件并重启服务。

为什么配置了 replicate_do_db 还是同步了其他库？

可能使用了 replicate_wild_do_table 或其他过滤规则，复制过滤规则存在优先级，需检查所有 filter 相关变量。

参考来源

• MySQL Official Documentation, Replication Filtering Options, https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html
• MySQL Official Documentation, CHANGE REPLICATION FILTER Statement, https://dev.mysql.com/doc/refman/8.0/en/change-replication-filter.html