关于GaussDB:数仓集群管理单节点故障RTO机制分析

摘要：大规模分布式系统中的故障无奈防止。产生单点故障时，集群状态和业务是如何复原的？

本文分享自华为云社区《GaussDB (DWS) 集群治理系列：单节点故障RTO机制剖析（集群状态复原篇）》，原文作者：CloudGanker 。

一、前言

GaussDB(DWS)产品采纳分布式架构设计。集群治理（高可用）须要在稳定性和灵敏性之间做好均衡。

集群产生单节点故障（如宕机、断网、下电等）时，端到端业务复原的RTO (Recovery Time Objective)流程和指标，次要蕴含两大过程：集群状态复原（CM Server主备倒换，DN/GTM主备倒换）和业务复原（CN可失常执行业务）。

本文关注集群状态复原局部，残余局部后续独自剖析。

参考链接：

GaussDB (DWS) 集群治理系列：CM组件介绍（架构和部署状态）
GaussDB (DWS) 集群治理系列：CM组件介绍（外围性能）

二、假如条件和要害配置参数

通常状况下故障CN主动剔除的触发工夫较长（默认10分钟），因而本文不波及CN剔除和实例修复的流程，也不探讨CN故障时DDL业务的中断。

假如如下：

1. 除明确故障外（如节点曾经宕机），链接可在超时工夫内胜利建设（即建设链接工夫按超时工夫计算）
2. 消息传递不耗费工夫
3. DN/GTM执行failover工夫不超过 T_{rm failover}_T_failover​ （通常小于5秒）

要害配置参数如下：
【CM侧配置参数】实例心跳超时instance_heartbeat_timeout（默认30秒）, 后续用 T_{rm hb}_T_hb​ 示意。

阐明：因为C/C++语言中乘法和除法不满足结合律，本文波及运算均为整数运算。

三、集群拓扑示例

疏忽CN的部署，以下图所示的三节点集群为例：

• 两个cm_server实例，主备别离部署在节点1和节点2
• 两个GTM实例，主备别离部署在节点1和节点2
• 一组DN实例，主备从别离部署在节点1，节点2和节点3
• 每个节点上均部署cm_agent组件

四、整体流程剖析

当节点1故障，集群将短时间处于不可用状态，而后主动复原至降级状态，随后可在CN上失常执行业务。因而，RTO流程的探讨可分为四个阶段。

1）单节点故障产生，集群处于不可用状态，cm_server/GTM/DN处于无主状态

2）cm_server备机升主，GTM/DN期待仲裁

3）GTM/DN备机（并行）升主，集群复原至降级状态

4）CN链接至GTM和DN，失常执行业务

以故障产生时刻为0时刻点，上面一一剖析每个阶段并计算相干工夫。

五、CM Server备机升主

单节点故障产生后，集群治理组件出于稳定性思考，并不会立即感知故障状态。两个cm_server实例之间通信时，依据心跳判断对方的存活状态。如果二者间心跳超时，则进入如下的自仲裁流程（对端链接均指与另一个cm_server的链接）。

六、DN/GTM备机升主

集群治理的仲裁采纳被动触发的模式。每个cm_agent检测所在节点的实例状态，并定期上报（固定距离1秒）至主cm_server；主cm_server综合各实例状态进行仲裁，而后将必要的仲裁后果发送至相干cm_agent；cm_agent收到仲裁后果，执行相应的命令。

以某个主 DN 故障为例，一次典型的仲裁流程包含：

① CM Agent 1探测DN主实例并发现故障
② CM Agent 1继续上报实例故障信息至CM Server
③ CM Server执行仲裁流程，抉择DN备机升主
④ CM Server下发升主命令至CM Agent 2
⑤ CM Agent 2对实例执行升主操作

对于单节点故障，DN和GTM实例的仲裁可同时进行，分步骤的工夫如下：

七、小结

将CM Server自仲裁和DN/GTM仲裁的工夫相加，即为集群状态复原的耗时（单位：秒）

用户可依据本身状况，通过调整instance_heartbeat_timeout参数抉择适合的RTO指标。

点击关注，第一工夫理解华为云陈腐技术~