分布式数据库容灾方案

导语：主备数据中心之间一般有热备、冷备、双活三种备份方式。相关内容参考：现代化数据中心的双活与灾备方案设计、数据中心灾备、双活解决方案交流、双活数据中心技术、双活数据中心解决方案技术白皮书、银行业双活数据中心解决方案。

分布式数据库容灾设计核心思想是就是充分利用分布式多副本数据一致性协议原理，并结合各种意外情况的具体特点，找到对应的解决方案。及时发现故障，准确分析故障原因在分布式数据库容灾过程中的关键。集群中任何节点的软硬件故障，或者任何节点之间的网络连接故障，都可能影响集群的正常工作。

由于其天然的复杂性，这个环境发生故障的几率并不低，因此分布式数据库系统需要将节点软硬件故障和网络故障当作常见情况来处理，而不是当作极低概率的事件来处理。下文从节点故障、网络故障、数据中心故障等维度重点介绍数据库容灾应对方案。

(一)节点故障

为了能描述系统容灾的过程，下面先对分布式数据库的常见节点故障处理过程进行介绍。

1.计算节点故障

分布式数据库的计算节点多采用多实例部署，且自身不维持状态。所以当一个计算节点故障后，负载均衡通过健康检查识别故障，自动把请求分发到其他的计算节点上。

待该节点自愈恢复后，负载均衡检测到节点正常服务，会自动将请求重新均衡到该计算节点上。

2.存储节点主库故障

当分布式数据库的存储节点集群出现主库故障，集群的健康检查模块会监测到主库故障，并通过多次探测确认故障。如果主库故障确认，系统会控制存储节点集群进行主从切换，将一个从库节点选举为新的主库节点，并调整集群的主从同步关系。同时集群拓扑的元数据会进行更新，推送到集群的各节点，包括查询路由相关信息。这样应用层的写操作会发送到新的主库。此时由于存在一个故障的副本节点，根据集群的副本策略和恢复机制，恢复系统会触发一个恢复任务，重新恢复一个新的从库节点加入集群。

3.存储节点从库故障

当分布式集群的一组主从出现从库节点故障，集群的健康检查模块会监测到从库故障，并通过多次探测来确认故障。如果确认从库故障，系统会将该从库进行下线处理。同时集群拓扑的元数据会进行更新，将该故障的从库节点从集群信息中删除，并推送到集群的各节点进行更新。查询路由相关的信息更新后，应用层的读操作不再发送到故障的从库。此时由于存在一个故障的副本节点，根据集群的副本策略和恢复机制，系统的恢复系统会触发一个恢复任务，重新恢复一个新的从库节点加入集群。

(二)网络故障

1.对查询的影响

专线网络抖动异常一般会带来延时和丢包。GaiaDB-X集群的计算服务节点、存储服务节点、管控节点之间的通讯都有完备的超时重试机制，少量的延时丢包不会影响查询性能，跨专线的主从延时会增大，待网络质量恢复后即恢复正常。

2.对写入的影响

采用分组半同步的集群，网络延时和丢包可能会造成同步延时甚至同步中断重连，影响写操作提交，导致部分事务提交失败。一般来说，分组半同步有两种应对策略：

一是支持配置同步退化超时时间，即延时超过一定时间后强同步退化为异步同步，可以减少链路异常对应用写入操作的影响，但同步退化后降级为异步同步，主从数据的强一致性已经不能保障。此时如果网络抖动蔓延成网络中断故障，出现存储节点集群切换后会出现数据丢失，即RPO>0。

二是应用需要最大程度保障数据一致性，由于网络抖动情况复杂，所以采用牺牲这段异常时间段的写入功能可用性，保持强同步策略。所有写入全部会被网络异常阻塞，等待人工处理或者网络恢复；实际情况应该根据数据库的业务要求采用不同的策略配置。

(三)同城双活生产中心灾难

以同城双活容灾架构为例，此处介绍遇到机房级灾难情况下系统的应对措施。

当生产中心机房出现严重灾难，导致大面积服务器和网络故障。这时灾备中心的数据库集群会监测到生产中心的计算节点和存储节点不可用，开始进行容灾应急处理。

首先系统会对生产中心的计算节点进行下线处理。由于生产中心的计算节点已经全部不可访问，系统会在元数据中将所有异常节点进行剔除，并调整负载均衡配置，生产中心的所有查询流量都只会发送到容灾中心的计算节点。同时系统对生产中心的存储节点进行下线处理。对于主库在生产中心的集群，按照存储节点主库故障的处理流程进行自动主从切换，将灾备中心的从库切换为主库；对于主库在灾备中心的集群，则按照存储节点从库故障的处理流程进行节点下线。

调整完成后更新集群元数据，所有存活的计算节点都会调整路由，将读写操作发送到新的容灾机房的存储节点集群；最后根据容灾策略，系统会对复本率不足的主从集群补充从库节点。整个容灾切换的处理示意图如下：

此时容灾中心的负载均衡入口可以承载全流量的业务压力，业务系统可自动或手动将流量全部转移到灾备中心的数据库集群。以一个四分片的分布式数据库为例，主从切换后，分片拓扑调整如下（不包括补充副本）：

在同城双活的容灾架构下，对分布式数据库容灾指标的特性进行分析。

1.数据库服务RTO

数据库服务的主要节点是计算节点和存储节点。下面针对两种节点的故障恢复进行分析。计算服务节点一般采用多实例部署，节点本身不保存数据和状态。通过负载均衡设备进行流量均衡；当一个计算节点发生故障后，往往可以在秒级内完成节点的故障转移。落到该故障节点的应用访问一般重试后即可恢复。

存储服务节点一般采用多分片和多副本的模式组建集群。出现存储节点故障情况下，数据库服务完成恢复时间包括四部分：

集群故障监测时间分布式数据库采用多重监测机制来保障故障感知的准确性：

节点监测：存储节点实例的可用性监测（服务进程状态、内存使用情况、磁盘设备状态）。单个存储节点的心跳是定时检测，当连续检测到一定次数的异常心跳，即判断节点故障。建议心跳连续验证次数配置不能太低，否则容易出现误切换；另外对于异地机房节点，建议增加连续验证次数，以防线路抖动触发误切换；
同步监测：获取集群各存储节点的同步关系的信息数据。通过分析所有存储节点的主从关系，验证其组成的拓扑关系正确性。这种监控不需要连续检测，一次检测即可发现集群异常；
集群监测：监测存储节点的存活和同步状态，保障切换的最小集群规模并避免反复切换。建议连续多次监测失败才能确认异常。

通过多种监测机制完成确认集群异常，建议通过配置测试各阶段的合理重复检测次数，使整体检测时间保持在10至20秒合理范围，过短的监测时间容易出现误感知导致误切换。

1) 主从切换准备

当存储服务主库节点异常时，需要启动主从切换流程进行故障转移。主从切换前，往往需要在仍然存活的副本中选举一个新主库，形成新集群拓扑。在新集群进行切换前，各存储节点根据同步机制不同，可能存在数据不一致的情况。所以接下来需要等待所有节点完成数据交换补齐，将各节点数据同步到最新状态。

2) 主从切换

节点全部完成同步后，所有存储节点的数据一致，此时重新调整主从关系，切换一般秒级即可完成。

3) 集群路由调整

完成切换后，配置节点中的集群拓扑结构会进行相应的调整，并同步到所有计算节点，时间与元数据同步周期有关，一般在数秒左右。

正常情况下，基于分布式数据库的多副本同步复制机制，在同步延时较小的集群上，RTO故障恢复时间应该可以保持在30秒到1分钟左右。

2.数据库服务 RPO

基于强同步机制的数据库服务可以实现数据无丢失，即RPO=0。实际的数据库应用场景中，RPO的能力取决于采用何种同步机制策略。如果应用系统容忍丢失少量数据，则可以采用异步同步机制，这样还可以提高集群写入性能，但RTO>0；如果应用系统严格要求数据完整性，则可以采用强同步机制，虽然集群写入性能会受到一定影响，但能保证故障切换后不丢失数据，即RPO=0。

一般来说，使用强同步后，事务提交的延时会增加大概一个集群节点网络间往返时延（Round-Trip Time，以下简称“RTT”）的最大值。以同城双活容灾架构为例，最大的RTT是两个同城机房间的网络交互延时，一般约为1至2毫秒。即开启强同步后，每个事务都会增加1至2毫秒的时间开销。

3.专线延时对查询的影响

分布式数据库的同城双活容灾架构下，数据是分布在两个机房的。如果查询请求所需的存储服务节点不在当前机房，就需要一次跨专线的访问。与跨机房的强同步类似，一次交互也需要额外的1至2毫秒时间开销。

(四)两地三中心主区域灾难

以两地三中心容灾架构为例，介绍遇到地理级灾难情况下系统的应对措施。当出现城市级重大灾难，位于该城市的生产中心和灾备中心出现大面积的服务器和网络故障，所有数据库节点均受到影响。异地灾备中心的数据库集群会监测到生产中心和同城灾备中心的计算节点和存储节点不可用，开始进行容灾应急处理。完成切换后的系统架构如下：