设为首页 收藏本站
查看: 492|回复: 0

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

[复制链接]

尚未签到

发表于 2016-10-23 09:11:35 | 显示全部楼层 |阅读模式
  大家都知道 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即可。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-290078-1-1.html 上篇帖子: MySQL 8小时空闲 连接池异常 could not execute query 下篇帖子: MySQL加非聚簇索引造成core dump及简单分析
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表