如何解决MySQL中gh-ost改双主表结构主键冲突问题，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
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修改表结构的工程中，如果是双主都有写入，则必须将写入切到单边，然后再进行修改
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联-成都网站建设公司行业资讯频道，感谢您对创新互联的支持。
