MySQL双主一致性架构优化

1.双主控保证高可用 MySQL数据库集群经常采用一主多从、主从同步、读写分离的方式来扩展数据库的读性能，保证读数据库的高可用性。不过，此时写入数据库仍然是单点。 在MySQL数据库集群中，可以设置两个主数据库，并设置双向同步，以冗余的方式保证写数据库的高可用性。 2.并发导致不一致 数据冗余会造成数据一致性问题，因为数据同步存在时间差，并发写入可能会导致数据同步失败，导致数据丢失： 如上图所示，假设主库使用自增作为自增主键： 在两个MySQL-master之间设置双向同步可以保证主数据库的高可用性。 数据库中现有记录的主键为1,2,3 主库1插入主键4的记录，并与主库2同步数据 在数据同步成功之前，主库2还插入了一条记录。由于数据还没有同步成功，所以插入的记录生成的主键也是4，数据也同步到了主库1。 主库1和主库2都插入了一条主键为4的记录，双主同步失败，数据不一致。 3.避免相同步长冲突 能保证两个主库生成的主键不会冲突吗？ 回答： 设置不同的初始值 设置相同的增长步长 只要能够做到就可以了。 如图所示： 在两个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的所有数据。即使一个主库出现故障，另一个主库也能保证库的高写入速度。可用的。 4. 上游生成ID以避免冲突 换句话说，为什么要依靠数据库的自增ID来保证数据的一致性呢？ 业务上游完全可以使用统一的ID生成器来保证ID生成不冲突： 如上图所示，调用者插入数据时，也可以通过引入全局***ID来解决这个问题，而不需要依赖数据库的自增。 至于如何生成全局***和趋势递增ID，请参考文章《分布式ID生成算法》。 5. 消除重复写入并不能解决根本原因。 使用自增同时写入两个主库可能会导致数据不一致。仅使用一个主库提供服务，另一个主库作为shadow-master，保证高可用性。一致性问题可以避免吗？ 如图所示：在两个MySQL-master之间设置双向同步可以保证主数据库的高可用性。 仅主库1提供对外写作服务 两个主库设置为同一个虚拟IP。当主库1挂掉或者网络异常时，虚拟IP自动漂移，影主在上，保证主库高可用。 由于这个交换机的虚拟IP不会改变，因此切换过程对于调用者来说是透明的，但在极端情况下，也可能会导致数据不一致： 如图所示： 两台MySQL-master设置双向同步，保证主库高可用，并设置相同的虚拟IP 网络抖动前，主库1向上游提供写入服务，插入一条主键为4的记录，并与shadow master主库2同步数据 突然主库1网络出现异常。 keepalived检测到异常后，进行虚拟IP漂移，主数据库2开始提供服务。 在主键4的数据同步成功之前，主库2插入了一条记录，同时也生成了一条主键4的记录，导致数据不一致。 6.内网DNS检测 双主同步延迟导致的虚拟IP漂移和数据不一致。本质上，虚拟IP偏移需要在双主同步数据完成后才能实现。利用内网DNS检测，可以实现shadow master延迟高可用： 使用内网域名连接数据库，例如：www.sychzs.cn 主库1和主库2设置双主同步。它们不使用相同的虚拟IP，而是分别使用ip1和ip2。 首先www.sychzs.cn指向ip1 使用小脚本轮询并检测ip1主库的连通性 当ip1主库出现异常时，小脚本延时x秒，等待主库2同步数据，然后解析www.sychzs.cn到ip2。 当程序重新连接内网域名时，会自动连接ip2主数据库，保证数据一致性。 七、总结 主库高可用，主库一致性，一些技巧： 双主同步是保证写库高可用性的常用方式。 设置相同的步长和不同的初始值可以避免自增生成冲突的主键。 对于业务调用者来说，不依赖数据库生成全局***ID是一个很好的方法。 Shadow Master保证写库的高可用。只有一个写入库提供服务，无法完全保证一致性。 内网DNS检测可以在主库1出现问题后，延迟一段时间，然后切换主库，保证数据一致性。 【本文为51CTO专栏作家“58申健”原创稿件，转载请联系原作者】 点击此处查看该作者更多好文章