MySQL部分表复制配置下存在的运维风险、原因及一种方案

  大家都知道 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即可。