摘要：大規模分佈式系統中的故障無法避免。發生單點故障時，集羣狀態和業務是如何恢復的？
本文分享自華爲雲社區《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業務的中斷。
假設如下：
- 除明確故障外（如節點已經宕機），鏈接可在超時時間內成功建立（即建立鏈接時間按超時時間計算）
- 消息傳遞不消耗時間
- DN/GTM執行failover時間不超過 T_{\rm failover}Tfailover （通常小於5秒）
關鍵配置參數如下：
【CM側配置參數】實例心跳超時instance_heartbeat_timeout（默認30秒）, 後續用 T_{\rm hb}Thb 表示。
說明：由於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指標。