MySQL binlog-do-db选项是危险的

很多人通过 binlog-do-db, binlog-ignore-db, replicate-do-db 和
replicate-ignore-db 来过滤复制(某些数据库), 尽管有些使用, 但是,在我看来,他们是危险的,并且他们被滥用了.
对于很多的实例,有更安全的替换方案

为什么危险很简单: 他们并不像你想的那样工作. 想象如下的场景: 你设置了 binlog-ignore-db = garbage, 所以 garbage数据库(在slave上不存在这个数据库) 中的数据不会被复制

mysql> delete from garbage.junk;
mysql> use garbage;
mysql> update production.users set disabled = 1 where user = "root";

复 制会broke2次, 第一次，因为 slave尝试着去之西你给第一条语句，但是slave上并没有这样的表"garbage.junk" ,
第二次, 隐含的, 因为 对 production.users不会被 复制,因为 root帐号并没有在slave上被禁用掉.

为 什么? 因为 binlog-ignore-db 并不像你想的那样执行, 我之前说的, "在garbage数据库中的数据不会被复制" 是错的,
实际上(数据库)并没有这么做.事实上, 他是通过默认的数据库为“garbage" 的连接, 过滤二进制的(SQL)语句日志的. 换句话说,
过滤不是基于 查询的字符串的, 而实际于你used的数据库.

其他我提到的配置选项也都类似. binlog-do-db 和 binlog-ignore-db 语句是特别危险的，因为他们将语句写入了二进制日志. 意味着你不能使用二进制日志从备份恢复指定时间的数据.

安 全的替换方案是 在 slave上配置过滤, 使用基于查询中真正涉及到的表的选项, 这些是: replicate-wild-* 选项, 例如,
避免复制 garbage数据库中的数据的安全的方案是 配置: replicate-wild-ignore-table=garbage.%.
这样做仍然有一些特殊的情况, 不能正常工作,但可以在更多的情况下正常工作,并且会遇到更少的意外 (gotchas).