【GaussDB关键技术原理|高可用】DCF双集群容灾

GaussDB关键技术原理：高性能篇，从GaussDB数据库性能优化系统概述、查询处理综述、高性能关键技术等方面为大家进行了解读，并对高斯数据库性能优化做了总结。本篇将分享GaussDB高可用方面的相关知识，详细介绍GaussDB的DCF与双集群容灾技术。

1 DCF

1.1 DCF（Distributed Consensus Framework）分布式一致性共识框架

1.2 DCF功能架构

1.3 DCF选举流程及优化

选举流程介绍：

预选举优化：

租约优化：

1.4 DCF日志复制流程

复制流程介绍：

1.5 DCF优先级选主和策略化多数派

优先级选主：

1.6 DCF性能设计

异步流水线：

数据合并与压缩：

批量并行落盘：

1.7 DCF日志与XLOG日志合一设计

1.8 DCF异常场景处理，高可靠

Leader故障

网络分区

2 双集群容灾

数据中心架构

核心优势

1 DCF

DCF是Distributed Consensus Framework的简称，它是自研分布式一致性共识框架，基于Paxos协议开发，实现多数派节点自选主自仲裁、日志复制、一致性控制等高可用功能。

1.1 DCF（Distributed Consensus Framework）分布式一致性共识框架

DCF部署于gaussdb进程，以动态库形式提供给DN调用，实现DN节点间自选主自仲裁、XLOG日志复制、回放控制等。DCF主要设计特点如下：

独立API数据复制与内核逻辑隔离；
基于Paxos一致性协议实现日志多副本复制，实现跨AZ极致高可用；
支持多种节点角色：leader、follower、candidate、passive、logger；
支持多日志流通道，支持DN粒度和分区粒度日志分组复制能力；
DCF内部实现通过多处的pipeline、batching、compress等手段提升整体性能。

1.2 DCF功能架构

DCF通过上层API提供给DB kernel调用，在DCF内部主要功能模块如下：

接口：对外提供写入、查询、注册回调等接口
选举：负责主节点的选举、心跳维持、状态通知
复制：负责日志的复制、提交、达成一致控制
元数据：负责管理集群配置信息
存储：负责日志数据的缓存管理和持久化
通信：提供节点间的数据通信功能，并支持压缩解压和SSL能力
基础库：提供线程、日志、锁、队列、定时器等基础能力

1.3 DCF选举流程及优化

选举流程介绍：

除了配置为不可当主的角色（logger、passive）外，启动时各节点一般默认是备机follower角色。节点启动后如果没有收到主节点的心跳，则达到选举超时时间后节点就会发起选主请求，如果节点收集到超过半数节点的应答则可升主。节点升主后会定期给其他节点发送心跳维持权威，其他节点收到心跳后作为备机工作。

每次选出新主都会产生一个新的任期term，这个term是单调递增的。当后续重新选主，term会跟着变大。

如果主节点故障，无法继续发送心跳，其他节点达到选举超时时间后会发起新一轮选举，集群选出新主，继续对外提供服务。

预选举优化：

为防止网络断连导致节点频繁发起选主请求造成term持续增加，采用了优化方案：在Follower变为Candidate前加入pre-candidate状态，发起term不变的预选举流程，成功后才将term增加发起正式选主流程，避免无效的term增加。

租约优化：

Leader与多数派断连主动降备，防止出现事实双主。

在lease时间内不再响应新的选主消息，保证选主可靠性。

1.4 DCF日志复制流程

复制流程介绍：

在集群有主的情况下，上层可以调用DCF写接口将日志写给DCF主节点，DCF主节点将日志复制给各个备机，日志并行在主机和各备机落盘，主机收集自身和各备机日志落盘的位置，从而计算得到达成多数派一致性的日志落盘位置，即一致性点。主机会将一致性点同步给备机，整个过程异步、并行、流水线处理。各个节点都有了实时一致性点，主机可以利用一致性点控制业务提交、脏页刷盘、checkpoint等流程，备机可以利用一致性点控制XLOG日志回放，保证业务一致性、各节点不分叉。

1.5 DCF优先级选主和策略化多数派

优先级选主：

（1）根据用户指定的AZ和节点优先级顺序，通过节点间信息交互及日志索取机制实现了确定性优先级选主。

（2）高优先级节点异常时，其他节点秒级感知，保证选主RTO。

（3）策略化多数派。

（4）支持灵活动态的策略化多数派，可通过参数配置。

（5）在发生AZ级或城市级故障时，能够在其他AZ选出新主，不丢失数据。

1.6 DCF性能设计

异步流水线：

日志采用全异步pipeline方式进行发送，不采用一问一答同步方式，且支持报文合并发送，提高系统整体吞吐量；

Leader发送完一批log之后，记录发送位置，下次发送从这个位置持续发送，不用等follower响应回来；

Follower落盘线程写完一批log之后，将最新的落盘点发送给leader，持续反馈最新的落盘点；

Leader通过各节点的最新落盘点，推进一致性点。

数据合并与压缩：

报文收发和工作线程采用异步pipeline；

基于端到端共识流控算法自适应调整batch size、 pipeline并发数，提升系统最大吞吐量；

支持将报文按不同压缩算法进行压缩发送，减少网络带宽。

批量并行落盘：

应用端调用write接口，写入内存buffer就返回，不阻塞应用流程处理；

批量写盘和批量发送，日志到buffer之后，并行的将日志落入本地磁盘和发送到follower节点。

1.7 DCF日志与XLOG日志合一设计

为了减少磁盘空间和IO带宽占用、优化性能，我们进行了DCF日志与XLOG日志合一设计，实现XLOG日志只写一份。

DCF日志头和配置日志放在DCF侧（称为控制日志ctrllog）以方便DCF内部处理，XLOG日志格式和之前保持兼容。ctrllog和XLOG建立内部索引关系，相比XLOG其日志量可以忽略不计。

使用XLOG刷盘点计算多数派一致性点，控制业务提交；XLOG刷盘点也是选主的依据。DCF控制日志刷盘以方便业务处理和故障恢复逻辑，限制DCF控制日志刷盘频率避免对XLOG刷盘影响，保证整体性能。

1.8 DCF异常场景处理，高可靠

Leader故障

如图，三节点集群，红色节点表示主机、蓝色表示备机，各节点旁边数字第一行表示日志index，第二行表示任期term，每一列表示一条日志。

leader节点宕机，导致Leader心跳发送停止，日志复制停止。

Follower检测到心跳超时，转换为candidate，发起新任期选举。

Follower若接收到其他节点发起的选举，则判断任期和日志长度，确定是否投票给它。

candidate若得到超过半数的选票，则成为leader，拥有新的任期term。

新leader开始将自己的日志发送给其他follower。

Follower接收新leader来的日志信息，判断日志是否跟自己连续匹配，连续匹配则接受。若不连续则返回，leader重新发送前段日志；若term不匹配，则将新leader的日志覆盖到原来的位置，并将后面的日志truncate掉。最终所有节点的日志都是一致的。

网络分区

五节点集群，分裂为3+2，如图所示：

集群脑裂，分裂出两个小集群。

2节点小集群存在一个原leader，3节点新集群选举一个新leader，任期增1。

原leader无法达成大多数一致，日志无法提交,一定时间内会降备。

新leader能接受写请求进行写入操作，能够达成一致，进行日志提交。

脑裂消失之后，新leader的日志复制给旧leader，将旧leader未提交日志覆盖，集群正常。

2 双集群容灾

GaussDB 双集群容灾方案，是GaussDB提供的一种新架构和部署方式的容灾技术。在已有的容灾方案中，多采用单集群多副本的模式进行跨AZ部署，无法做到故障隔离，类似于集群管理组件的故障或其他区域性的故障将导致整个集群服务不可用；对于传统的基于网络的日志同步方式，数据库主备节点间地理距离的增大将导致传输时延的大幅度增加，直接影响到生产服务的性能。同时，金融、银行业对数据安全有着较高的要求，需要最大限度地保证数据的安全性以及服务的可用性。因此，GaussDB提供了支持RPO=0的数据库双集群容灾方案，即主集群在出现故障的情况下，备集群还具备继续提供服务的能力，当发生自然或人为灾难时，保护数据并快速进行恢复，对数据丢失零容忍。

数据中心架构

双集群部署方式，即每个数据中心分别部署一套独立的GaussDB数据库集群，其中一个数据库集群作为生产集群，提供读和写服务，另一个集群作为灾备集群。
每个数据中心都分别有一个独立的Region和AZ，用来部署GaussDB数据库集群。全量build同步通过云内跨Region跨VPC的BMS之间的网络承载，增量日志同步通过Dorado之间的主备复制承载。
主集群的Redo日志通过网络同步到备集群的存储设备中，主集群的备节点从存储设备中读取Redo日志并进行回放，备集群的备节点从所在分片的存储设备中读取Redo日志并进行回放。当数据库主节点写入的日志同步到备集群的存储设备之后，主节点的事务才会被提交，从而确保了集群切换RPO=0的性能指标。
数据存储不使用本地盘，而是采用Dorado（全闪存共享存储阵列），即每个GaussDB数据库集群都配置一套独立的Dorado作为存储；两套Dorado之间采用主备同步复制，数据复制的模式支持最大保护模式和最大可用模式。
数据中心内部实例级故障时，RPO=0、RTO<=30秒；跨数据中心集群间容灾时，RPO=0、RTO<=60秒。
在同城双集群容灾的基础上，可以和异地集群组成跨Region容灾，即增加一个异地的灾备中心，用于对同城双中心的数据备份，形成两地三中心的容灾解决方案。