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

本文根据阿里云技术专家田英鹤（喜乐）在蚂蚁金服&阿里云在线金融技术峰会上《云数据库系统容灾架构设计和实践》的分享整理而成。本次分享分为背景（为什么要容灾）、识别故障&常见容灾架构、云数据库机房容灾架构和未来发展四部分。分享中，喜乐重点讲解了一主一备、一主多备、三节点自动选主等常用的数据库容灾架构，并对云数据库机房不同情形下的容灾，给出了相应的解决方案。

直播视频：点击此处观看

幻灯片下载： 点此进入

以下为整理内容。

---

什么是容灾？为什么要容灾？

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

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

 

图一 如何做到“高可用/容灾”

正如上图所示，整个容灾体系分为很多层（本文的重点是数据高可用层）：

• 业务的高可用主要体现在游戏分区、地域单元化等操作上，不仅仅是解决服务器压力的问题，同时也是为容灾考虑。
  
• 应用架构高可用保障主要包括：Web端的负载均衡、应用的无状态，消息的可重复投递等操作。
  
• 数据库高方面可以通过一主多备、读写分离以及自动Failover等部署实现高可用的保障。
  
• 在硬件、存储方面，高可用的保障措施包括硬件冗余、Raid、共享存储等。
  

数据库故障识别

数据库远程探测主机或实例通常是通过数据库外部短连接进行更新或查询记录的方法直观地探测数据库是否可用，根据查询或更新的结果感知故障情况。

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

（一）当出现连接超时，说明发送SYNC包或回包的过程发生中断，或者是主机掉电，路由丢失导致。

（二）当出现连接成功，但返回Reset包的情况时，说明当前主机可以连接，但进程不存在，可以认为是进程挂掉了，比如发生了OOM，或软件BUG导致的进程crash等故障。

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

（三）当出现连接成功，Socket超时或SQL超时（hang）的情况时，说明主机可以连接，端口在监听，但数据库无法响应。这种故障是目前所有故障中最难判断的一种，一般需要结合采集实时DB性能、主机存储数据和网络性能信息进行综合判断。

（四）当出现连接成功，更新报错或者DB层连接失败的情况时，说明数据库内存产生了错误，如too many connection等问题，这类错误是由于数据库的使用不当或客户端的驱动存在问题导致，这种问题不是主机的故障，需要进行应用级别的告警，而非实例级别的failover。

 

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

上面所讲的都是一对一探测模式，除此之外还有一对多的探测模式，例如三节点探测模式。

ä¸è点探测模式最重要的是可以通过选举协议（如RAFT协议）选取一个leader，然后由内部通信判断哪一个节点是孤岛，也就是少数派自动降级，不再对外提供服务，同时结合外部的HA进行链路上的Failover或切换，从而规避了双写问题的出现，使得实例的可用性达到最大。

机房故障检测

图五 机房故障检测

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

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

当机房级别的故障产生时，一般不建议进行全自动化切换。因为在机房出现故障时，很难判断到底是机房内哪一部分出现了问题。但如果将机房容灾做成一个产品，外部一旦触发机房故障切换动作（这个过程可以是人来判断或半自动化判断，切换的过程可以是自动化操作），就可以按照之前的预案进行容灾操作。

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

 

数据库常见容灾架构

 

图六 如何保证数据可靠性

在金融行业内保证数据的可靠性是非常重要的前提。通常所讲的数据可靠性包括两个方面：RPO和RTO，最好的情况是RPO为零，RTO最小，RPO为零意味着所有的数据均不丢失，数据完整；RTO最小意味着对用户的影响最小。

更多情况下，我们考虑的是多机之间的互备；实际上，单机单库情况下某些点也是非常重要的：

第一点，硬盘方面采用SAS、SATA或SSD均可，重点是做RAID5/RAID10，同时RAID卡带备用电池BBU；
第二点，做到日志盘与数据盘分离，因为顺序读/写和随机读/写对磁盘的要求是不同的。
第三点，日志及时转移，避免在主机堆积，所有数据库级别采取的日志都需要转移到第三方存储上。
第四点，注意FSYNC vs ASYNC mysql的“双1”配置，pgsql的sync配置，因为性能和安全二者不可得兼，需要在不同的业务的DB上选择合适的配置，要选择在断电情况下，数据文件，日志文件结构能保证完整的数据库，如PG，MSSQL。
第五点，注意SSD的磨损指数、机架的功率负载、机器的质保期等等，当然云计算条件下这些自己就不用考虑了。
第六点，注意进行及时的数据备份、日志备份。

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

一主一备

 

图七 一主一备架构

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

该架构的优点是：架构简单，资源利用少、成本较低；但是它的可靠性并不是很高，这是因为主备之间采用半同步模式，但并不能保障数据的完全不丢失，当网络和主库同时断开时，备库和主库的数据一定是不同步的，此时会有少量的数据丢失。

一主多备

图八 一主多备架构

业内的通用观点是：副本越多，系统的可用性和可靠性越高。在一主多备的架构下，主库与备库之间的的同步方式是强同步，但不是master对所有slave强同步，而只对其中半数以上的slave强同步即可。链路切换过程主要分为master RO、choose slave、wait sync to master on slave、switch Route、slave RW五步。切换后处理相比较一主一备更加复杂些，因为所有备库的复制源已经发生变化，当选中的备库作为主库后，则其他备库的复制源都要重新指向新的主库。

该架构的优点：可靠性和可用性大大增强；缺点也是显而易见的：由于备库增多，成本也随之增加。

三节点自动选主

图九 三节点自动选主架构

三节点自动选主是另一种常见的架构，三节点组成Replica Set架构。该架构采用RAFT协议自动选择主节点，此时HA不需要外部干预，三节点相互通信，自主决定哪一节点成为新主库。自动选主后，HA通过外部探测新的主库节点，然后再从外部将数据链路切换到新的主库节点上。后续的工作是旧主库尝试重启，并且重搭复制，加入副本集。

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

 

图十 共享存储架构

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

链路切换过程十分简单，因为它不涉及master RO、Wait sync to master on slave外部操作。切换后处理也需要进行元数据更新，以及旧主库重搭（重搭的代价很小）、旧主库只读、旧主库与新主库复制关系搭建等操作。

共享存储的优点是架构比较简单，上层的server切换非常轻量；缺点是共享存储必须保证可靠，这是因为共享存储也并非单点结构，数据需要写多份。

 

云数据库机房容灾

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

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

图十二 机房预期切换

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

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

图十三 机房非预期切换

非预期切换是指发生故障时进行的切换，常见的导致机房故障的因素包括地震、火灾、停电等等。在机房发生故障时，由主机房切换至备机房的顺序和预期切换大致雷同，首先完成控制系统的切换；然后再进行业务实例切换，其中有一点值得注意：在业务实例切换过程中，必须将原主机房的业务流量切断，同时停掉全部的应用、实例，最大限度地保障两个机房的数据完全一致。

数据可靠性很大程度上依赖两个机房数据库之间的复制关系，以及可用可靠性配置。

图十四 机房间网络故障

机房故障还有另外一种情况：机房之间的网络断开。机房内网络出现问题比机器掉电发生的概率要大得多。机房之间的网络断开同样会导致脑裂问题的产生。应对这类情况，可以通过三节点模式判断哪个节点断开，成为孤岛；如果只有两个机房，可以在每个机房内选择若干点，同时探测对端机房的核心交换机、路由器等网络设备，如果所有的埋点都不通，则认为对端机房发生规模性的故障。当规模性故障发生时，HA不进行切换操作，从而保证主机两端不会发生双写。

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

图十五 两地三中心

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

对于同步复制的双机房，如果每个机房内只部署一个服务器，当主备机房之间网络断开时，可能由于部分应用部署在备机房，而数据库部署在主机房，那么会造成应用的部分服务器不可服务。导致部分应用不可用。如果采用Doubble-binlog的解决方案，主备机房进行半同步复制，主库写入任何日志同步到备库之后，再对用户进行返回。当主备机房之间网络断开，半同步模式自动降级为异步复制模式。Doubble-binlog在由异步之后回切半同步模式时，提供了两条Binlog复制模式，从最新的主库写入的位点同步到备库上，只要中间的日志空洞被填满，就可以保障数据的完整性，同时也加快了数据同步的速度。

 

未来

图十六 未来发展规划

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