“老司机”和你聊聊云数据库系统容灾那些事

  • 时间:
  • 浏览:1
  • 来源:大发欢乐生肖APP下载_大发欢乐生肖APP官网

在金融行业内保证数据的可靠性是非常重要的前提。通常所讲的数据可靠性包括有一两个方面:RPO和RTO,最好的清况 是RPO为零,RTO最小,RPO为零原因所有的数据均不丢失,数据完整性;RTO最小原因对用户的影响最小。

更多清况 下,大伙儿考虑的是多机之间的互备;实际上,单机单库清况 下你这一点也是非常重要的:

一主多备

阿里云数据库容灾是伴随着阿里云数据库发展而不断进步的,在12年仅有v0.1开发版本;在13年支持MySQL、SQLserver;在14年支持水平扩展、支持防闪断链路、支持区域单元化;在15年支持PostgreSQL、PPAS、跨机房容灾、double-binlog克隆模式;今年,阿里云数据库支持三节点MongoDB、Redis、RedisSharding以及Greenplum。

当机房级别的故障产生时,一般不建议进行全自动化切换。之后在机房跳出故障时,先要判断到底是机房内哪一每段跳出了疑问报告 。但之后将机房容灾做成有一两个产品,内控 一旦触发机房故障切换动作(你这一过程可不可不可以 是人来判断或半自动化判断,切换的过程可不可不可以 是自动化操作),就可不可不可以 按照以前的预案进行容灾操作。

图九 三节点自动选主架构

第你这一,硬盘方面采用SASSATASSD均可,重点是做RAID5/RAID10,一块儿RAID卡带备用电池BBU

第二点,做到日志盘与数据盘分离,之后顺序读/写和随机读/写对磁盘的要求是不同的。第三点,日志及时转移,处置在主机堆积,所有数据库级别采取的日志都还要转移到第三方存储上。第四点,注意FSYNC vs ASYNC mysql的“双1”配置,pgsqlsync配置,之后性能和安全二者不可得兼,还要在不同的业务的DB上选者大概的配置,要选者在断电清况 下,数据文件,日志文件特性能保证完整性的数据库,如PGMSSQL第五点,注意SSD的磨损指数、机架的功率负载、机器的质保期等等,当然云计算条件下哪些自己就不想考虑了。第六点,注意进行及时的数据备份、日志备份。

哪些是容灾?为哪些要容灾?

本文根据阿里云技术专家田英鹤(喜乐)在蚂蚁金服&阿里云在线金融技术峰会上《云数据库系统容灾派发和实践》的分享派发而成。本次分享分为背景(为哪些要容灾)、识别故障&常见容灾架构、云数据库机房容灾架构和未来发展四每段。分享中,喜乐重点讲解了一主一备、一主多备、三节点自动选主等常用的数据库容灾架构,并对云数据库机房不同清况 下的容灾,给出了相应的处置方案。

 

数据库故障识别

 

图十五 两地三中心

该架构的优点是:架构简单,资源利用少、成本较低;之后它的可靠性并都会很高,这是之后主备之间采用半同步模式,但都有也不我能保障数据的完整性不丢失,当网络和主库一块儿断开时,备库和主库的数据一定是不同步的,此都会有极少量的数据丢失。

三节点探测模式最重要的是可不可不可以 通过选举协议(如RAFT协议)选者有一两个leader,之后由内控 通信判断哪有一两个节点是孤岛,也也不我少数派自动降级,不再对外提供服务,一块儿结合内控 的HA进行链路上的Failover或切换,从而规避了双写疑问报告 的跳出,使得实例的可用性达到最大。

 

前面的讲的都会share-noting架构,存储是相互独立的。下面讲一下share-disk架构,即共享存储架构。共享存储架构中master和slave都会server层,两者的存储都会在本地。使用共享存储居于切换时,master server挂掉以前切到slave上,下面的共享存储仍旧正常,可直接通过数据对外提供服务。之后事物日志和数据文件相互分离,slave接管以前还要将事物日志应用下去,从而原因recovery的时间会很长。之后使用共享存储架构时,事物日志一定要保留的尽之后短。

图四 数据库远程探测主机或实例可用性的常用方式

数据库常见容灾架构

一主一备

对于同步克隆的双机房,之后每个机房内只部署有一两个服务器,当主备机房之间网络断开时,之后之后每段应用部署在备机房,而数据库部署在主机房,这麼会造成应用的每段服务器不可服务。原因每段应用不可用。之后采用Doubble-binlog的处置方案,主备机房进行半同步克隆,主库写入任何日志同步到备库以前,再对用户进行返回。当主备机房之间网络断开,半同步模式自动降级为异步克隆模式。Doubble-binlog在由异步以前回切半同步模式时,提供了两条Binlog克隆模式,从最新的主库写入的位点同步到备库上,我希望中间的日志空洞被填满,就可不可不可以 保障数据的完整性性,一块儿也加快了数据同步的强度。

非预期切换是指居于故障时进行的切换,常见的原因机房故障的因素包括地震、火灾、停电等等。在机房居于故障时,由主机房切换至备机房的顺序和预期切换大致雷同,首先完成控制系统的切换;之后再进行业务实例切换,其富含你这一值得注意:在业务实例切换过程中,还要将原主机房的业务流量切断,一块儿停掉完整性的应用、实例,最大限度地保障有一两个机房的数据完整性一致。

一主一备是最常见的也是最简单的数据库容灾架构,一主一备通常采用Share-nothing特性,两边存储相互独立。在一主一备的清况 下,为了保证可靠性,DB间的数据同步方式采用的是半同步模式。链路切换过程最为重要的四步包括master RO、wait sync to master on slave、switch Route、slave RW。每个步骤都会有超时、回滚以及主库故障时的对应方式。切换后,元数据还要进行更新,之后主库角色之后居于了改变;旧主库还要进行重搭、只读之后与新主库克隆关系搭建等操作。

 

上图显示的是金融行业内常用的两地三中心部署架构,该架构创新使用Double-binlog/半同步模式。基本的特性包括主机房、备机房、灾备机房。主备机房居于同有一两个地方,灾备机房居于异地。主备机房之间通常采用同步克隆方式,减少用户的RT时间;异地机房之间采用异步克隆模式。

双机房部署时,当两边的机房都部署了HA,最重要的是要处置HA的脑裂,之后两边的HA都想接管自己机房的实例,之后判断发现对端机房服务器不可达、连接超时,而本机房DB备库可用时,则之后会启动备库提供服务。但你这一清况 不应该跳出,之后两边的数据库都会主库,会跳出双写清况 居于。在双机房部署时,实现机房级别的容灾,应该处置应用跨机房访问,或跨机房访问后,能自动关闭应用,流量自动failover。

(一)当跳出连接超时,说明发送SYNC包或回包的过程居于中断,之后是主机掉电,路由丢失原因。

图八 一主多备架构

图二 数据库远程探测主机或实例可用性的常用方式

机房级别的容灾分为预期切换和非预期切换一种生活模式。

图十二 机房预期切换

链路切换过程十分简单,之后它不涉及master RO、Wait sync to master on slave内控 操作。切换后处置也还要进行元数据更新,以及旧主库重搭(重搭的代价很小)、旧主库只读、旧主库与新主库克隆关系搭建等操作。

实际中,之后所有的应用和存储都上放一边,当有一两个机房之间网络断开时,用户有之后是不受任何影响的。

三节点自动选主是另一种生活常见的架构,三节点组成Replica Set架构。该架构采用RAFT协议自动选者主节点,此时HA不还要内控 干预,三节点相互通信,自主决定哪一节点成为新主库。自动选主后,HA通过内控 探测新的主库节点,之后再从内控 将数据链路切换到新的主库节点上。后续的工作是旧主库尝试重启,之后重搭克隆,加入副本集。

图十三 机房非预期切换

 

以下为派发内容。

数据库远程探测主机或实例通常是通过数据库内控 短连接进行更新或查询记录的方式直观地探测数据库是是不是可用,根据查询或更新的结果感知故障清况 。

业内的通用观点是:副本不想 ,系统的可用性和可靠性越高。在一主多备的架构下,主库与备库之间的的同步方式是强同步,但都会master对所有slave强同步,而只对其中半数以上的slave强同步即可。链路切换过程主要分为master RO、choose slave、wait sync to master on slave、switch Route、slave RW五步。切换后处置相比较一主一备更加多样化些,之后所有备库的克隆源之后居于变化,当选中的备库作为主库后,则你这一备库的克隆源都会重新指向新的主库。

图六 怎么保证数据可靠性

该架构的优点:可靠性和可用性大大增强;缺点也是显而易见的:之后备库增多,成本也随之增加。

图七 一主一备架构

预期切换是指正常地从主库切到备库,此时不居于任何故障,将主机房内将完整性的应用、数据切换到备机房。大致切换顺序为:第一步切换控制系统,将任务流引擎、监控报警组件、备份、数据派发、API等从主机房切换到备机房;第二步,将业务实例切换到备机房。在整个切换过程中,之后管控系统的高可靠和应用组件的高可用,之后在正常切换过程中,数据无任何丢失。

幻灯片下载: 点此进入

云数据库机房容灾

(四)当跳出连接成功,更新报错之后DB层连接失败的清况 时,说明数据库内存产生了错误,如too many connection等疑问报告 ,例如错误是之后数据库的使用不当或客户端的驱动居于疑问报告 原因,你这一疑问报告 都会主机的故障,还要进行应用级别的告警,而非实例级别的failover。

图十六 未来发展规划

图三 数据库远程探测主机或实例可用性的常用方式

共享存储的优点是架构比较简单,上层的server切换非常轻量;缺点是共享存储还要保证可靠,这是之后共享存储也都有也不我单点特性,数据还要写多份。

三节点自动选主

数据可靠性很大程度上依赖有一两个机房数据库之间的克隆关系,以及可用可靠性配置。

一般意义上来讲,容灾是指异地的机房与主机房之间进行容灾。但在实际生活中,同机房或同城双机房都可不可不可以 称之为容灾。

通常机房故障都被认为是大面积故障,例如整个机房断电、整个机房火灾或有一两个机房之间的网络断开等清况 。

中间所讲的都会一对一探测模式,除此之外还有一对多的探测模式,例如三节点探测模式。

未来

图十四 机房间网络故障

直播视频:点击此处观看

正如上图所示,整个容灾体系分为何都层(本文的重点是数据高可用层):

图五 机房故障检测

(二)当跳出连接成功,但返回Reset包的清况 时,说明当前主机可不可不可以 连接,但tcp连接运行运行不居于,可不可不可以 认为是tcp连接运行运行挂掉了,比如居于了OOM,或软件BUG原因的tcp连接运行运行crash等故障。

图十一 阿里云数据库容灾发展历程

如上图所示,左侧和右侧分别是单独的机房,机房内控 的探测系统可不可不可以 从内控 探测机房内的清况 ,这其富含有一两个很容易被忽略的关键点:不仅仅还要探测机房内的主机或服务器实例,探测机房之间核心路由器、交换机等网络设备也是至关重要。通过机房主机间二层网络探测是最直接、方便的探测方式,可不可不可以 直观地反应机房当前的网络清况 。

机房故障还有另外一种生活清况 :机房之间的网络断开。机房内网络跳出疑问报告 比机器掉电居于的概率要大得多。机房之间的网络断开同样会原因脑裂疑问报告 的产生。应对例如清况 ,可不可不可以 通过三节点模式判断哪个节点断开,成为孤岛;之后只有有一两个机房,可不可不可以 在每个机房内选者若干点,一块儿探测对端机房的核心交换机、路由器等网络设备,之后所有的派发都会通,则认为对端机房居于规模性的故障。当规模性故障居于时,HA不进行切换操作,从而保证主机两端不想居于双写。

该架构的优点是具有较高的可用性和可靠性;缺点是之后数据库引擎不同,不同引擎之间的源码实现、业务逻辑千差万别,还要根据不同的引擎特性进行细致的筛选和验证。

下面来看一下常见的数据库容灾架构。

图一 怎么做到“高可用/容灾”

容灾最重要的是利用冗余资源最大限度的保证系统服务的连续性、可靠性。此外,容灾利用的冗余资源不仅仅指的是机房,也包括主机级别、DB实例级别、硬件、应用架构和业务。

机房故障检测

过去,阿里云服务器专注的方向更多是多引擎;未来,阿里云服务器的目标是实现全方位、快速识别故障,一块儿做到全自动化Failover,将机房级别的故障以产品化的方式提供出来,由用户自主操作、选者符合业务场景的切换模式,实现定制化服务。

图十 共享存储架构

(三)当跳出连接成功,Socket超时或SQL超时(hang)的清况 时,说明主机可不可不可以 连接,端口在监听,但数据库无法响应。你这一故障是目前所有故障中最难判断的一种生活,一般还要结合派发实时DB性能、主机存储数据和网络性能信息进行综合判断。