gh-ost改变双主表结构时如何解决MySQL主键冲突问题

1）背景：

最近帮助业务方排查了两起主主复制数据丢失或主键冲突的案例。 DB端的同事也问我这是什么。原理是什么？在回答他们的同时，我也会记录这个问题。

2）现象：

公司南北业务采用主主复制，表主键为自增ID。各主库自增ID错开，但业务主键存在主键冲突。起初以为是设置或修改不当造成的，但是查看历史记录ds，没人做过，而且配置也正确，也没人重启；在调查binlog时，发现了一个有趣的现象。在MySQL主库的binlog中，出现了两条主键ID相同的binlog，它们是insert生成的binlog。具体现象如下：

17:19分一首

17:22分一首

开始我感到很困惑。即使主键相同，如何仍然插入到同一个表中？然后突然想到这应该是gh-ost改变表结构导致的（公司DBA严重不足，部分DB操作只能是业务运维的一部分）

3）模拟分析：

前提：假设有两个双主，分别称为主库A和主库B。上面有一张表T。 T表只有一个主键。在ghost修改表之前，我们称其为T，m修改后的表为T'（T和T'实际上是同一张表，只是创建时叫法不同，方便起见）

①主库B执行重命名表T to T_old,new_t TO T操作，此时主库A为T'表

②同时主库A插入T表13的数据，但主库B还没有没收到（延迟关系）

③主库A的T表通过重命名表T修改为T_old,new_t TO T从主库传过来B，变成T'；由于主库B中的T'表还没有收到第二步发送的13，所以主库A中的T'表一定不会有值13

④Main At这次，A库向T'插入了13，正在复制到B主库的T'（由于延迟，尚未发送到主库T'表）

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

⑥第四步主库A写入T'的13已经传给了主库B，发现B主库的T'表已经有13了（从第五步开始），然后是主键冲突

至此，主键冲突的原因已经找到了。这种冲突就意味着数据丢失（这个分析需要你对gh-ost的原理有充分的了解）

4）如何避免

在使用gh-ost的项目中修改表结构，如果两个master都写的话，必须把写的内容切到一侧再修改

阅读以上内容对您有帮助吗？如果您想了解更多相关知识或阅读更多相关文章，请关注行业资讯频道。感谢您的支持。