我C,MySQL双主架构,原来能这么玩

经常有朋友问,MySQL双主的一致性问题,今天简单聊一聊。

 

MySQL为什么要使用双主架构

MySQL最常见的集群架构,是一主多从,主从同步,读写分离的架构。通过这种方式,能够扩充数据库的读性能,保证读库的高可用,但此时写库仍然是单点。

 

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

MySQL双主架构,会存在什么问题?

如果MySQL双主架构,同时提供服务,可能会引发数据的一致性问题。因为数据的同步有一个时间差,并发的写入可能导致数据同步失败,引起数据丢失

 

举个栗子:

我C,MySQL双主架构,原来能这么玩

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

(1)两个MySQL主库设置双向同步可以用来保证主库的高可用;

(2)数据库中现存的记录主键是1,2,3;

(3)主库1插入了一条记录,主键为4,并向主库2同步数据;

(4)数据同步成功之前,主库2也插入了一条记录,由于数据还没有同步成功,插入记录生成的主键也为4,并向主库1也同步数据;

(5)主库1和主库2都插入了主键为4的记录,双主同步失败,数据不一致

 

能否在MySQL层面,保证两个主库生成的主键一定不冲突呢?

可以的,只需要为两个主库的自增ID:

(1)设置不同的初始值

(2)设置相同的增长步长

 

我C,MySQL双主架构,原来能这么玩

如上图所示:

(1)两个MySQL主库设置双向同步可以用来保证主库的高可用;

(2)库1的自增初始值是1,库2的自增初始值是2,增长步长都为2;

(3)库1中插入数据主键为1/3/5/7,库2中插入数据主键为2/4/6/8,不冲突;

(4)数据双向同步后,两个主库会包含全部数据

我C,MySQL双主架构,原来能这么玩

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

 

上述方案,依赖与数据库的配置,能不能由应用程序,来保证数据的一致性呢?

答案是肯定的,应用程序使用统一的ID生成器,可以保证ID的生成不冲突。

我C,MySQL双主架构,原来能这么玩

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

画外音:如何生成全局唯一趋势递增的ID,不展开。

 

引发不一致的根本原因,是保证高可用的两个主库都对外提供服务,如果只有一个主库对外提供服务,另一个主库平时不提供服务,仅仅在主库挂了的时候提供服务,能否消除上述数据不一致呢?

答案是悲观的,仍然不行。

使用虚IP+keepalived的方式保证数据库主库的高可用,平时只有一台主库提供服务,也可能出现数据不一致。

我C,MySQL双主架构,原来能这么玩

如上图所示:

(1)两个MySQL主库设置双向同步可以用来保证主库的高可用;

(2)只有主库1对外提供写入服务;

(3)两个主库设置相同的虚IP,在主库1挂掉或者网络异常的时候,虚IP自动漂移,备用主库顶上,保证主库的高可用;

 

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

我C,MySQL双主架构,原来能这么玩

如上图所示:

(1)两个MySQL主库设置双向同步,可以用来保证主库的高可用,并设置了相同的虚IP;

(2)网络抖动前,主库1对上游提供写入服务,插入了一条记录,主键为4,并向备用主库2同步数据;

(3)突然主库1网络异常,keepalived检测出异常后,实施虚IP漂移,备用主库2开始提供服务

(4)在主键4的数据同步成功之前,主库2插入了一条记录,也生成了主键为4的记录,结果导致数据不一致

 

有没有办法缓解上述问题呢?

虚IP漂移,双主同步延时导致的数据不一致,本质上,需要在双主同步完数据之后,再实施虚IP偏移

 

使用内网DNS探测,缓解上述问题:

(1)使用内网域名连接数据库,例如:db.kg.org

(2)主库1和主库2设置双主同步,不使用相同虚IP,而是分别使用ip1和ip2;

(3)一开始db.kg.org指向ip1;

(4)用一个小脚本轮询探测ip1主库的连通性;

(5)当ip1主库发生异常时,脚本delay一个x秒的延时,等待主库2同步完数据之后,再将db.kg.org解析到ip2;

(6)应用程序以内网域名进行重连,即可自动连接到ip2主库,并保证了数据的一致性;

画外音:本质上,这是一个可用性与一致性的折衷。

 

总结

MySQL主库高可用,主库一致性,一些小技巧:

(1)双主同步是一种常见的保证写库高可用的方式;

(2)设置相同步长,不同初始值,可以避免auto increment生成冲突主键;

(3)不依赖数据库,业务调用方自己生成全局唯一ID是一个好方法;

(4)双主保证写库高可用,只有一个写库提供服务,并不能完全保证一致性;

(5)内网DNS探测,可以实现在主库1出现问题后,延时一个时间,再进行主库切换,以保证数据一致性,但牺牲了几秒钟的高可用;

 

希望大家有收获,谢转。

 

原创功能恢复了,“喜可贺”。

账号被罚了,有点不开心

账号被罚了,申诉的结果出来了,果然

发布者:糖太宗,转载请注明出处:https://www.qztxs.com/archives/science/technology/6578

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022年5月14日 上午12:42
下一篇 2022年5月14日 上午12:44

相关推荐

  • Redis为什么这么快? Redis底层实现原理

    前言 说起当前主流NoSql数据库非 Redis 莫属。因为它读写速度极快,一般用于缓存热点数据加快查询速度,大家在工作里面也肯定和 Redis 打过交道,但是对于Redis 为什么快,除了对八股文的背诵,好像都还没特别深入的了解。 今天我们一起深入的了解下redis吧: 高效的数据结构 Redis 的底层数据结构一共有6种,分别是,简单动态字符串,双向链表...

    2022年5月19日
    3100
  • Windows日志事件ID说明

    日志路径:C:WindowsSystem32winevtLogs查看日志:Security.evtx、System.evtx、Application.evtx如何查看:右键我的电脑-管理-系统工具-事件查看器,或者eventvwr查看事件查看器 打开Windows系统的事件查看器,右键单击系统或安全日志,选择筛选当前日志,在筛选器中输入下列事件ID即可。 &...

    技术 2022年6月13日
    23200
  • 应用开发安全指南

    1.概述 本指南是IT安全保障体系建设规范的一个组成部分,全面阐述了IT系统应用开发整个软件生命周期所必须遵照的设计、编码、测试方面的安全要求,阐述了不同开发环境和编码语言条件下安全开发的相关规范要求。   1.1.目的 本指南针对xxxx应用系统应当遵循的应用开发安全标准进行了规范性说明,旨在指导应用系统设计人员、代码开发人员和安全检查管理人员进...

    技术 2022年5月27日
    1400
  • 选redis还是memcache,源码怎么说?

    memcache和redis是互联网分层架构中,最常用的KV缓存。不少同学在选型的时候会纠结,到底是选择memcache还是redis。 画外音:不鼓励粗暴的实践,例如“memcache提供的功能是redis提供的功能的子集,不用想太多,选redis准没错”。   虽然redis比memcache更晚出来,且功能确实也更丰富,但对于一个技术人,了解“所以然”...

    2022年5月15日
    2400
  • 缓存,原来我们一直都用错了!

    缓存,是互联网分层架构中,非常重要的一个部分,通常用它来降低数据库压力,提升系统整体性能,缩短访问时间。   有架构师说“缓存是万金油,哪里有问题,加个缓存,就能优化”,缓存的滥用,可能会导致一些错误用法。   4类缓存常见误用,你中招了吗?   误用一:把缓存作为服务与服务之间传递数据的媒介。 如上图: (1)服务1和服务2约定好key和value,通过缓...

    2022年5月10日
    2700

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

联系我们

400-800-8888

在线咨询: QQ交谈

邮件:admin@example.com

工作时间:周一至周五,9:30-18:30,节假日休息

关注微信