單一實例快速恢複

執行個體快速恢複邏輯說明

• Hologres在 V2.0版本之前，Hologres計算節點均為容器調度（即下圖中的Worker Node），資源管理員（Resource Manager）負責周期性健全狀態檢查。當出現1分鐘容器響應逾時（可能是記憶體溢出、硬體故障、軟體Bug等原因導致），Resource Manager會自動拉起新的計算節點，並遷移資料分區（Shard）職責到新的節點上（例如Worker Node3響應逾時，Resource Manager拉起Worker Node4取代Worker Node3），實現系統狀態的快速恢複。資料狀態儲存在Apsara Distributed File System分布式儲存系統中，無需從計算節點遷移，計算節點輕量無狀態，系統可以快速從故障中恢複。該方案為當前每個執行個體內部預設啟用，當系統發生故障時，無需手工營運介入，系統可以自動回復。在恢複期間，如果查詢運算元需要訪問恢複中的節點，則查詢會立即失敗。節點恢複速度在一分鐘左右，當表數量明顯增加時，恢復會更長。

• Hologres從 V2.0版本開始增加快速恢複機制，針對大規格執行個體，可以利用Worker的片段資源，加快恢複速度，減小對於線上業務的影響。當執行個體Worker數達到一定規模時，可以在一定數量Worker故障時，使用其他正常的Worker快速載入故障Worker原始分配Shard的中繼資料。

• 執行個體規模和允許故障的Worker數量如下表所示：

  計算資源數量	執行個體節點數量	允許故障的Worker數量
  160CU <= 執行個體計算資源 < 320CU	10 <= 執行個體節點數量 < 20	1
  320CU < 執行個體計算資源	20 <= 執行個體節點數量	2

• 由於臨時使用了其他正常的Worker快速載入故障Worker原始分配Shard的中繼資料，所以可以達到快速恢複的目的。

情境範例說明

預設情況下，執行個體的Worker節點會均勻的載入Shard的中繼資料。例如下圖所示，執行個體包含10個Worker，存在10個Shard，那麼每個Worker都會載入1個Shard。

此時若Worker 2 發生故障，執行個體會檢測到故障後10秒內使用其他的Worker（Worker 1）載入Shard 2的中繼資料，以起到快速恢複的作用。

當節點重啟被拉起後，系統不會自動將Shard的中繼資料載入到重新拉起的節點上，即Shard 2中繼資料還是會載入在Worker 1中。如果發現觸發快速恢複後負載不均衡，可以執行Rebalance命令，使執行個體最終達到負載平衡的狀態，Rebalance命令詳情請參見均衡分區（Rebalance）。