ITPub博客

首页 > 数据库 > MySQL > 【MySQL】gh-ost改双主表结构主键冲突问题

【MySQL】gh-ost改双主表结构主键冲突问题

原创 MySQL 作者:风尘_NULL 时间:2020-02-21 19:42:08 0 删除 编辑

1)背景:

最近帮业务方排查了两例主主复制丢数据或者主键冲突的问题,DB侧的同事也问我这是什么一个原理,在解答他们的同时,顺便也把这个问题记录一下

2)现象:

    公司一南北业务采用主主复制,而且该表的主键是自增ID,每个主库的自增ID是错开的,但是业务的主键却出现了主键冲突,开始以为是设置不当,或者认为修改造成,但是翻看历史记录,没人有过操作,而且配置也正确,没人重启;在调查binlog中,发现了一个有意思的现象,MySQL的一个主库binlog中出现了两条主键ID是一样的binlog,而且是insert产生的binlog,具体现象如下:

17:19分一条

    

17:22分钟的一条

    

    开始自己的感觉是懵逼的,怎么主键相同,还能插入同一张表?后面猛然一想,这应该是gh-ost改表结构造成的(本公司DBA严重不足,部分DB操作只能让业务运维也承担一部分了)

3)模拟分析:

   

    前提:假设有两个双主,分别叫主库A与主库B,上面存在表T,T表只有一个主键,在ghost修改之前的表,我们叫T,修改之后的表是T'(T跟T'其实是同一张表,只是产生的时间不同的叫法,方便表示)  

主库B进行rename table T to T_old,new_t TO T操作,这时候主库A是T'表了

同时主库A插入T表13的数据,但是主库B还没收到(延迟关系) 

主库A的T表被主库B传过来的rename table T to T_old,new_t TO T修改,变成了T';由于T'表在主库B还没收到第二步发过来的13,所以主库A的T'表肯定也没13这个值

主库A在这时又向T'插入13,正在复制给主库B的T'中(由于延迟,还没发送到主库的T'表)

主库B的T'接收到第二步主库A插入T的13

第四步主库A写入T'的13已经传到主库B,发现B主库的T'表已经有了13(第五步过来的),然后主键冲突

到此,主键冲突的原因已经找到,这种冲突意味着数据有丢失(此分析需要你对gh-ost的原理有充分的理解)

4)如何避免

    在用gh-ost修改表结构的工程中,如果是双主都有写入,则必须将写入切到单边,然后再进行修改

    


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30221425/viewspace-2676301/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Not only a DBA(纸上读来终觉浅,绝知此事需躬行)

注册时间:2015-04-24

  • 博文量
    69
  • 访问量
    201649