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修改表结构的工程中，如果是双主都有写入，则必须将写入切到单边，然后再进行修改