市面上关于MySQL高可用方案五花八门:Keepalived,3M,MHA,甚至通过负载均衡,proxy中间件等等方案来实现。那么怎么来对这些选型做评判呢?
本文将围绕下面的主线逻辑进行探讨:
在讨论高可用考量之前我们来看一个简单的高可用架构模型(下图);这个模型很简单,有一个HA的工具去检测主从状态,发现主实例异常后,就发生故障切换,切换前可能还需要做一些提升(Promote)的操作,比如数据补全,最后才绑定服务IP(ServiceIP),对外提供流量。
上面的模型是一个比较经典的高可用模型,用过高可用的同学应该能对号入座,没用过的同学会对高可用有一个基本的印象。
有了对高可用功能的简单刻画,我们回到本章正题,来探讨高可用的考量;熟悉Oracle的同学,应该都知道Oracle的Data Guard。DG是Oracle推出的一种针对Oracle数据库的高可用性数据库方案。它有三种工作模式: 最大性能,最大可用,最大保护。所以针对MySQL的高可用性考量,那么我们同样定义了类似的标准:
到这里,似乎我们得到了一套高可用的考量标准,我们的问题马上又接踵而至。
问题1:如何平衡一致性和性能?
问题2:如何平衡一致性和连续性?
上面的两个问题我们暂且卖个关子,到高可用选型的章节里在给大家展开探讨!
上一章我们谈论了高可用的考量,这一节我们要探讨高可用要处理哪些层级的故障,不同故障场景下,考量的适用度是多少?
故障检测的目的是保证某一节点故障时, HA能及时获得通知, 并开启修复或切换任务。节点故障包括由硬件故障, 网络故障,操作系统故障, 被监控软件故障, 或监控软件的故障引起的节点状态异常或失去响应。
硬件故障可能是可恢复的, 也可能不可恢复. 由于无法全面且准确地预测硬件故障的发生时间/发生种类/产生的影响等, 一般对硬件故障的检测方法如下:
什么意思呢,无法预测?那要我们高可用软件做什么?别急!大家考虑一下,如果我们要检测一个硬件故障,大致的思路其实是有的,无非就是去检测硬件的错误码,回头想想,光磁盘的供应商何其多,如果要把兼容性做齐,这个工程量可想而知;所以我们的结论是预防大于治疗。
比如电源故障我们要上备用电池(BBU),磁盘做Raid,网卡做Bond等等一系列的运维规范。那么无非防范的其他的硬件故障,我们依赖于高层应用的抛错来检测,比如系统报错disk read only,MySQL abort server等等。
PS:高可用是一个运维体系,除了高可用软件,还需要配套运维规范;这也是为啥DBA年限越久价值越大的一种体现吧!
网络故障也可以细分成以下几类。
网络不可用指较长时间网络通路不可用, 可通过节点间心跳来检测.
网络闪断指较短时间内网络在可用和不可用状态间震荡. 可将心跳检测的超时时间设为能容忍的网络闪断的最长时间 t,即容忍最长t时间的网络中断, 超时则认为网络中断。
网络稳定性和延迟可以由以下特征量进行描述,节点间的网络通讯协议需能正常工作于由以下特征量描述的某网络上
大部分的高可用软件会覆盖前两类场景,但是在不同的用户环境下,网络的质量其实是参差不齐的。如何在差网络条件下,高可用软件仍能够正常工作,不会有过多的误判?可行的一种实现方式是:在差网络条件下,高可用的检测敏感度要按比例降低。
类似于硬件故障, 无法全面且准确预测其发生时间/发生种类/产生的影响. 类似于硬件故障的检测方法。
类似于硬件故障的逻辑,对于部分系统故障我们要做防范,比如磁盘禁用cache,MySQL的 O_DIRECT 方式可以跳过pagecache写数据,MySQL的参数innodb_flush_log_at_trx_commit=1,sync_binlog =1等等。
除了预防,我们还要接外援的监控,因为让一个高可用软件告诉你,磁盘快要满了,似乎不太合适,这些是监控告警擅长的事情。
被监控软件的故障检测,不能简单检测其进程是否存在,还需要根据其特点进行细致的检测。针对MySQL, 我们用一张思维导图来展示如下图:
MySQL的故障不但要处理MySQL的健康问题,复制是MySQL的冗余手段,对于复制的检测修复,同样是需要一个高可用软件去容错的。
监控软件的故障常见的有:
对监控软件来说,自身的故障也是一类故障。通常由于监控软件相比于被监控软件其规模较小,且其测试着重于可用性测试,故其发生故障的概率较低,不易受重视。通用的处理手法是使用守护进程,在监控软件意外退出时进行守护。但远远不够。
问题3:监控软件自身的可用性如何保障?
上面我们讨论的故障都是单点的故障,如果回到高可用集群自身,还有一类故障是不容忽视的,那就是脑裂!
HA到Master之间的连接不通,认为主库Crash。选择将备库提升为主库。但实际上,只是HA到Master间的网络有问题,原主库是好的(没有被降级为备库,或者是关闭),仍旧能够对外提供服务。新的主库也可以对外提供服务。两个主库,产生双写问题,我们说集群脑裂了。
问题4:如何解决脑裂问题?
这一章我们探讨了不同层次故障场景,需要通过不同的手法来避免可用性问题,比如增加运维规范,对接外援监控,同时对高可用软件需要做网络环境的适配,做细致的故障场景的拆分和处理等。
同时我们遗留了两个问题:
问题3:监控软件自身的可用性如何保障?
问题4:如何解决脑裂问题?
有故障场景,有考量标准后,这一章我们来探讨如何选型。选型的讨论我们围绕着遗留四个问题进行展开
一致性 & 性能
问题1:如何平衡一致性和性能?
一致性 & 连续性
问题2:如何平衡一致性和连续性?
集群可用性
问题3:监控软件自身的可用性如何保障?
问题4:如何解决脑裂问题?
一致性的需求是数据零丢失(全同步复制);性能的需求是性能最大化(异步复制);这从概念上来讲是两个极端,中间要选个平衡的话,半同步方案就可能脱颖而出。我们在工程实现中做了更多,我们不但选型了半同步的方案,我们还会探讨异步复制的方案!
半同步的简要实现见下图。
由于事务提交操作返回给应用时,事务产生的日志在主备两个数据库上都已经存在了。因此,此时主库Crash的话,备库提供服务,其数据与主库是一致的,没有任何事务的数据丢失问题。主备数据强一致实现。当然这个方案存在一定的限制:
因为存在限制2,如何让半同步方案更优雅一些,不走两个极端?
所以高可用手段如果选型的半同步,高可用必须接管HA的调度,包括但不限于:
在半同步的方案中,我们依赖半同步binlog在slave上先落盘,事务在提交的方式来保障一致性;那么异步复制如何来解决一致性问题呢?我们引入了一个外部技术,引入外部技术会降低整集群的可用性,但是它带个了我们无法拒绝的特性,数据一致性!通过binlog落共享存储盘,切换时争抢主机端binlog盘来补偿数据,保障数据不丢失,如下图
整个对共享存储磁盘的控制,是通过国际标准的Scsi PR协议完成磁盘注册,预留,抢占;
通过binlog共享存储的方式,因为只需要异步复制,也就很好的平衡了数据一致性和性能的问题!
到底应该听谁的?我们提出了SLA的概念。SLA服务等级协议(简称:SLA,全称:service level agreement),是业务根据需求与SLA组件签订的保障数据一致性或服务连续性的等级协议;
RPO协议规定了允许丢失的数据量(默认是零丢失)。用户可自行配置。
数据一致性级别分为两大类:P级别,能正常保障RPO协议;PE级别,不能保证RPO协议(需要人工干预)。
数据一致性级别每大类下有若干小级别,是根据主从延时的粒度进行的细分。
RTO协议规定了允许服务停止的时间(默认是10分钟)。用户可自行配置。
数据连续性级别分为两大类:T级别,能正常保障RTO协议;TE级别,不能保证RTO协议(需要人工干预)。
数据连续性级别每大类下有若干小级别,是根据数据丢失的粒度进行的细分。
定义了RPO和RTO协议后,HA在运行时,按照绑定的协议来进行切换即可。
HA自身可用性?脑裂?我们可以通过引入一致性选举算法,比如Paxos,Raft协议,来解决上面提到的两个问题;HA集群化部署,各节点之间角色对称;一致性选举算法选举出leader,由leader来做HA的所有决策(如下图,左边是单点部署,右边集群部署),由此我们解决HA自身单点的问题。当右边HA1从网络中割裂出去的时候,一致性选举算法需要超过众数节点才能选举,(HA1将失去众数节点,HA2和HA3将构成新集群),由此我们解决HA集群的脑裂的问题。
我们对这个架构又进行了升级:如下图
左边的架构图一:HA节点即是agent端,也可能是mgr端(如果被选举为leader)如果有上百个节点的时候,这个集群可能存在一个问题,比如集群要重新做一次选举,那么上百个节点间需要做通信,所以全民选举的效率会很低;适合小规模的高可用集群。
右边的架构图二:HA天然的分成agent端和mgr端。如果有上百个节点的时候,只会有上百个agent节点,mgr端可以控制在一个小规模的集群范围内,保障选举的效率,适合大规模的高可用集群。
如何平衡一致性&性能,我们的实现:
如何平衡一致性&连续性,我们的实现:
如何解决集群可用性,HA自身可用性和脑裂
写到最后,我们通过对MySQL高可用考量的定义,覆盖的故障类型和选型实现做了一些相对细致的谈论,但是对其的话题其实远远没有结束;
那么什么是金融级的MySQL高可用方案?我们对金融级的定义是:“稳定性、强一致,连续性”金融级MySQL高可用方案脱胎与金融业,但是可以适用在更为广泛的场景。
拥有丰富的一二线MySQL运维经验;先后在阿里云、爱可生担任数据库运维;目前为爱可生数据库产品负责人,MySQL技术专家。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞10
添加新评论0 条评论