一、双主保证高可用

MySQL数据库集群常使用一主多从，主从同步，读写分离的方式来扩充数据库的读性能，保证读库的高可用，但此时写库仍然是单点。

在一个MySQL数据库集群中可以设置两个主库，并设置双向同步，以冗余写库的方式来保证写库的高可用。

二、并发引发不一致

数据冗余会引发数据的一致性问题，因为数据的同步有一个时间差，并发的写入可能导致数据同步失败，引起数据丢失：

如上图所述，假设主库使用了auto increment来作为自增主键：

• 两个MySQL-master设置双向同步可以用来保证主库的高可用
• 数据库中现存的记录主键是1，2，3
• 主库1插入了一条记录，主键为4，并向主库2同步数据
• 数据同步成功之前，主库2也插入了一条记录，由于数据还没有同步成功，插入记录生成的主键也为4，并向主库1也同步数据
• 主库1和主库2都插入了主键为4的记录，双主同步失败，数据不一致
  
  

三、相同步长免冲突

能否保证两个主库生成的主键一定不冲突呢？

回答：

• 设置不同的初始值
• 设置相同的增长步长
  
  

就能够做到。

如上图所示：

• 两个MySQL-master设置双向同步可以用来保证主库的高可用
• 库1的自增初始值是1，库2的自增初始值是2，增长步长都为2
• 库1中插入数据主键为1/3/5/7，库2中插入数据主键为2/4/6/8，不冲突
• 数据双向同步后，两个主库会包含全部数据
  
  

如上图所示，两个主库最终都将包含1/2/3/4/5/6/7/8所有数据，即使有一个主库挂了，另一个主库也能够保证写库的高可用。

四、上游生成ID避冲突

换一个思路，为何要依赖于数据库的自增ID，来保证数据的一致性呢？

完全可以由业务上游，使用统一的ID生成器，来保证ID的生成不冲突：

如上图所示，调用方插入数据时，带入全局唯一ID，而不依赖于数据库的auto increment，也能解决这个问题。

至于如何生成全局唯一，趋势递增的ID，参见文章《分布式ID生成算法》。

五、消除双写不治本

使用auto increment两个主库并发写可能导致数据不一致，只使用一个主库提供服务，另一个主库作为shadow-master，只用来保证高可用，能否避免一致性问题呢？

如上图所示：

• 两个MySQL-master设置双向同步可以用来保证主库的高可用
• 只有主库1对外提供写入服务
• 两个主库设置相同的虚IP，在主库1挂掉或者网络异常的时候，虚IP自动漂移，shadow master顶上，保证主库的高可用
  
  

这个切换由于虚IP没有变化，所以切换过程对调用方是透明的，但在极限的情况下，也可能引发数据的不一致：

如上图所示：

• 两个MySQL-master设置双向同步可以用来保证主库的高可用，并设置了相同的虚IP
• 网络抖动前，主库1对上游提供写入服务，插入了一条记录，主键为4，并向shadow master主库2同步数据
• 突然主库1网络异常，keepalived检测出异常后，实施虚IP漂移，主库2开始提供服务
• 在主键4的数据同步成功之前，主库2插入了一条记录，也生成了主键为4的记录，结果导致数据不一致
  
  

六、内网DNS探测

虚IP漂移，双主同步延时导致的数据不一致，本质上，需要在双主同步完数据之后，再实施虚IP偏移，使用内网DNS探测，可以实现shadow master延时高可用：

• 使用内网域名连接数据库，例如：db.58daojia.org
• 主库1和主库2设置双主同步，不使用相同虚IP，而是分别使用ip1和ip2
• 一开始db.58daojia.org指向ip1
• 用一个小脚本轮询探测ip1主库的连通性
• 当ip1主库发生异常时，小脚本delay一个x秒的延时，等待主库2同步完数据之后，再将db.58daojia.org解析到ip2
• 程序以内网域名进行重连，即可自动连接到ip2主库，并保证了数据的一致性
  
  

七、总结

主库高可用，主库一致性，一些小技巧：

• 双主同步是一种常见的保证写库高可用的方式
• 设置相同步长，不同初始值，可以避免auto increment生成冲突主键
• 不依赖数据库，业务调用方自己生成全局唯一ID是一个好方法
• shadow master保证写库高可用，只有一个写库提供服务，并不能完全保证一致性
• 内网DNS探测，可以实现在主库1出现问题后，延时一个时间，再进行主库切换，以保证数据一致性
  
  

一、双主保证高可用

MySQL数据库集群常使用一主多从，主从同步，读写分离的方式来扩充数据库的读性能，保证读库的高可用，但此时写库仍然是单点。

在一个MySQL数据库集群中可以设置两个主库，并设置双向同步，以冗余写库的方式来保证写库的高可用。

二、并发引发不一致

数据冗余会引发数据的一致性问题，因为数据的同步有一个时间差，并发的写入可能导致数据同步失败，引起数据丢失：

如上图所述，假设主库使用了auto increment来作为自增主键：

• 两个MySQL-master设置双向同步可以用来保证主库的高可用
• 数据库中现存的记录主键是1，2，3
• 主库1插入了一条记录，主键为4，并向主库2同步数据
• 数据同步成功之前，主库2也插入了一条记录，由于数据还没有同步成功，插入记录生成的主键也为4，并向主库1也同步数据
• 主库1和主库2都插入了主键为4的记录，双主同步失败，数据不一致
  
  

三、相同步长免冲突

能否保证两个主库生成的主键一定不冲突呢？

回答：

• 设置不同的初始值
• 设置相同的增长步长
  
  

就能够做到。

如上图所示：

• 两个MySQL-master设置双向同步可以用来保证主库的高可用
• 库1的自增初始值是1，库2的自增初始值是2，增长步长都为2
• 库1中插入数据主键为1/3/5/7，库2中插入数据主键为2/4/6/8，不冲突
• 数据双向同步后，两个主库会包含全部数据
  
  

如上图所示，两个主库最终都将包含1/2/3/4/5/6/7/8所有数据，即使有一个主库挂了，另一个主库也能够保证写库的高可用。

四、上游生成ID避冲突

换一个思路，为何要依赖于数据库的自增ID，来保证数据的一致性呢？

完全可以由业务上游，使用统一的ID生成器，来保证ID的生成不冲突：

如上图所示，调用方插入数据时，带入全局唯一ID，而不依赖于数据库的auto increment，也能解决这个问题。

至于如何生成全局唯一，趋势递增的ID，参见文章《分布式ID生成算法》。

五、消除双写不治本

使用auto increment两个主库并发写可能导致数据不一致，只使用一个主库提供服务，另一个主库作为shadow-master，只用来保证高可用，能否避免一致性问题呢？

如上图所示：

• 两个MySQL-master设置双向同步可以用来保证主库的高可用
• 只有主库1对外提供写入服务
• 两个主库设置相同的虚IP，在主库1挂掉或者网络异常的时候，虚IP自动漂移，shadow master顶上，保证主库的高可用
  
  

这个切换由于虚IP没有变化，所以切换过程对调用方是透明的，但在极限的情况下，也可能引发数据的不一致：

如上图所示：

• 两个MySQL-master设置双向同步可以用来保证主库的高可用，并设置了相同的虚IP
• 网络抖动前，主库1对上游提供写入服务，插入了一条记录，主键为4，并向shadow master主库2同步数据
• 突然主库1网络异常，keepalived检测出异常后，实施虚IP漂移，主库2开始提供服务
• 在主键4的数据同步成功之前，主库2插入了一条记录，也生成了主键为4的记录，结果导致数据不一致
  
  

六、内网DNS探测

虚IP漂移，双主同步延时导致的数据不一致，本质上，需要在双主同步完数据之后，再实施虚IP偏移，使用内网DNS探测，可以实现shadow master延时高可用：

• 使用内网域名连接数据库，例如：db.58daojia.org
• 主库1和主库2设置双主同步，不使用相同虚IP，而是分别使用ip1和ip2
• 一开始db.58daojia.org指向ip1
• 用一个小脚本轮询探测ip1主库的连通性
• 当ip1主库发生异常时，小脚本delay一个x秒的延时，等待主库2同步完数据之后，再将db.58daojia.org解析到ip2
• 程序以内网域名进行重连，即可自动连接到ip2主库，并保证了数据的一致性
  
  

七、总结

主库高可用，主库一致性，一些小技巧：

• 双主同步是一种常见的保证写库高可用的方式
• 设置相同步长，不同初始值，可以避免auto increment生成冲突主键
• 不依赖数据库，业务调用方自己生成全局唯一ID是一个好方法
• shadow master保证写库高可用，只有一个写库提供服务，并不能完全保证一致性
• 内网DNS探测，可以实现在主库1出现问题后，延时一个时间，再进行主库切换，以保证数据一致性