大家都知道 replicate-wild-do-table可以配置只同步部分表，由于其支持通佩符，带来便利。但也存在一些风险。
问题描述：
假设M、S两个MySQL Server, S设置为M的从库，且设置replicate-wild-do-table=test.a%.
此时在M库按照如下顺序操作：
1) create table a1(f int);
2) alter table a1 rename to b1;
3) alter table b1 rename to a1;
此时分别在M、S中show tables发现，M中有a1, S中只有b1.
原因是步骤3没有在S中重放。
相关代码：
在主从过程中，从库S会将主库的所有命令都写入本地日志，但在执行之前会先判断是否符合replicate[-wild]-do-table的条件。
从库判断表名是否符合同步条件则是在rpl_filter.cc:tables_ok中，判断的输入是thd.lex.query_tables。 而对于alter语句，在解析过程中仅将源表信息放入query_tables中，导致在执行步骤3时，判断b1不符合模式a%, 因此不予重放。
换个策略也不行：
第一反应是是否可以对于alter语句将目标表也放入tables_ok中判断？当然可以，但就算改成这个策略，仍不能解决这个问题。可以看看这个操作序列。
1) create table a1(f int);
2) alter table a1 rename to b1;
3) alter table b1 rename to c1;
4) alter table c1 rename to a1;
可以看到就算是新策略，步骤3在S中仍然无法重放，在M执行步骤4的时候，S上仍会报错(c1不存在)
运维风险：
因此这个不算MySQL的bug，但在我们平时使用时却存在风险：我们在在线DDL的时候，经常会把一个表先转储到一个临时表中，在临时表中做完擦作后再替换原表。若此时从库上用replicate-wild-do-table作了限制，而临时表又不符合这个条件，则当主库在将临时表替换原表的时候，会导致从库上不会执行此操作，造成不一致。
当然如果我们足够小心，使用一个符合条件的表名作临时表就没这问题了，关键是：这个是要靠人小心来保证，不保险----ddl之前还要去确认所有从库上的配置，也挺麻烦。
一个方案：
出现此问题的最根本原因，是在S上执行步骤2时，将表名从符合a%条件的a1改成b1，导致之后的不可逆。
因此可以在从库上增加一个配置，是否允许重放这种命令。
只需要在判断是否重放的位置，增加判断目标表名是否符合replilcate-wild-do-table的条件，若不符合，直接返回执行失败。并报错到Last_error中。
剩下的就是配合监控了。监控后就可以按照需要重新处理，如需要让S继续重放以免M重新操作，则在S中把临时表的文件名也加入replicate-wild-do-table即可。
