关于复制过滤规则，其中一篇文档写得非常详细，参考：[MySQL 复制过滤详解](https://yq.aliyun.com/articles/59268)。详细解读这个文章后，知道复制过滤应该要如果配置，配置后应该注意些哪些点。 如下是总结的配置建议： 1、建议binlog_format配置使用row，主从数据一致性很重要，没有理由不选择（除非特殊业务，会产生特别大的binlog日志） 2、复制过滤使用--replicate-wild-do-table 或者 --replicate-wild-ignore-table，其它复制过滤参数建议不用配置。（无论binlog是row还是statment，都是最安全的） 3、5.7以后版本可使用CHANGE REPLICATION在线调整过滤，不过得记得同步在配置文件中也要添加，避免重启后复制过滤丢失。 这里再在如上的文档中补充一点，关于Create database,drop database,alter database （后称库级别ddl）操作，在配置从库复制过滤规则里需要知道的细节。特别在做drop database操作时，更要三思。 对于库级别的ddl，除了Replicate_Do_DB外，其它复制过滤可能和理解的不一样。 举例1： Replicate_Ignore_DB：replcation_db 主库执行库级别ddl: create/alter/drop database replcation_db，是能正常同步到从 举例2： Replicate_Wild_Do_Table：test_db.% 主库执行库级别ddl: create/alter/drop database replcation_db，是能正常同步到从 举例3： Replicate_Wild_Ignore_Table：replcation_db.% 主库执行库级别ddl: create/alter/drop database replcation_db，是能正常同步到从 如果要只同步某一个库的库级别ddl，只有Replicate_Do_DB是生效的： Replicate_Do_DB：replcation_db_test 主库执行库级别ddl: create/alter/drop database replcation_db，不能正常同步到从 所以，上游执行库级别ddl时，需要特别注意： 1、确认是否有下游 2、确认是否需要将ddl操作同步到下游 3、确认下游中是否有相应的数据库 最后再举一个真实案例： 在一个多源复制环境下，多源S实例从A，B，C三个源复制数据，但都只是同步ABC中的某一个库。 Replicate_Wild_Do_Table：A_db.%,B_db.%,C_db.% 统计需要，在S实例进行跑相应的数据，结果数据存储在S实例的R_db中。由于历史原因，在C实例中有一个空库R_db，最后在清理无用库时，将C实例的R_db库执行了drop database R_db,导致将S实例的R_db库也drop掉了，最终悲剧发生了，辛好是还有备份，但也只能慢慢等待备份数据恢复，还丢失了部分数据。