MySQL部分表复制配置下存在的运维风险、原因及一种方案-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

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

简介:

大家都知道 replicate-wild-do-table可以配置只同步部分表,由于其支持通佩符,带来便利。但也存在一些风险。

问题描述:

假设MS两个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;

此时分别在MSshow 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;

可以看到就算是新策略,步骤3S中仍然无法重放,在M执行步骤4的时候,S上仍会报错(c1不存在)

运维风险:

因此这个不算MySQLbug,但在我们平时使用时却存在风险:我们在在线DDL的时候,经常会把一个表先转储到一个临时表中,在临时表中做完擦作后再替换原表。若此时从库上用replicate-wild-do-table作了限制,而临时表又不符合这个条件,则当主库在将临时表替换原表的时候,会导致从库上不会执行此操作,造成不一致。

当然如果我们足够小心,使用一个符合条件的表名作临时表就没这问题了,关键是:这个是要靠人小心来保证,不保险----ddl之前还要去确认所有从库上的配置,也挺麻烦。

一个方案:

出现此问题的最根本原因,是在S上执行步骤2时,将表名从符合a%条件的a1改成b1,导致之后的不可逆。

因此可以在从库上增加一个配置,是否允许重放这种命令。

只需要在判断是否重放的位置,增加判断目标表名是否符合replilcate-wild-do-table的条件,若不符合,直接返回执行失败。并报错到Last_error中。

剩下的就是配合监控了。监控后就可以按照需要重新处理,如需要让S继续重放以免M重新操作,则在S中把临时表的文件名也加入replicate-wild-do-table即可。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章
最新文章
相关文章