KunlunDB的Fullsync高可用機制簡介

前言

KunlunDB具備完善的容災和錯誤處理機制，通過分散式事務兩階段提交演算法，以及Fullsync和Fullsync HA機制，可以確保在叢集執行期間任意計算節點、儲存節點、cluster_mgr等元件發生當機、重啟等故障或者發生網路分割槽（network partition）或者斷連時，叢集管理的使用者資料以及後設資料都會是一致的和完整的，不會丟失使用者已提交事務的任何資料更新，也不會發生事務部分提交部分回滾等不一致情況，以及發生使用者的後設資料與使用者資料不一致等情況。

KunlunDB基於兩階段提交協議實現可靠的分散式事務處理，確保在叢集任意多個節點故障時，叢集資料完全一致，保障所有事務的ACID 。

這一塊詳細內容請見這裡（ ）和這裡（ ），而kunlun-storage的Fullsync機制在這裡介紹過（ ）。

本文詳細介紹Fullsync高可用機制，下文簡稱Fullsync HA。

KunlunDB的Fullsync機制確保一個kunlun-storage的storage shard（儲存叢集）在提交任何一個事務完成後並且返回給客戶端成功確認之前，必須收到fullsync_consistency_level個備機的ACK確認收到了這個事務的binlog。

計算節點只有收到儲存節點的提交成功確認，才會返回給KunlunDB的客戶端應用，因此才有義務保障這些事務的永續性（durability），否則就沒有這樣的義務。

如果主節點和最多fullsync_consistency_level-1個備節點同時當機，仍然有1個備節點（fullsync_consistency_level>1時）含有全部已確認提交的事務的binlog，所以這些事務的更新不會丟失。

KunlunDB的Fullsync HA確保任何kunlun-storage發生主節點故障或者網路分割槽，都可以及時發現這些錯誤並且及時選舉新的主節點繼續承擔這個storage shard的寫入負載，下文將詳述。

KunlunDB的Fullsync和Fullsync HA機制確保了只要一個含有2*N+1個節點的kunlun-storage儲存shard只要還有N+1個節點在執行，這個shard就可以持續寫入。

這裡的N就是kunlun-storage的fullsync_consistency_level。

KunlunDB的fullsync和fullsync HA機制實現了等價於Raft協議的高可用機制，可以確保一個KunlunDB叢集的每個儲存shard的主節點可以有一個或者多個備節點與主節點資料同步。

對於fullsync_consistency_level=N（N > 1) 的一個或者多個fullsync儲存shard來說，即使這些儲存shard的主節點和N-1個備機同時發生任何故障或者網路斷連隔離等等問題，KunlunDB可以確保這些shard資料不丟失並且與叢集其他儲存shard保持資料一致性，並且KunlunDB會自動選出新的主節點並且提供讀寫能力。

主節點探活

KunlunDB的Fullsync HA確保主節點當機、重啟或者發生網路分割槽（network partition）後，可以自動啟動選主流程，完成主備切換，保障儲存叢集持續可用。

為了確認每一個storage shard的主節點可用，cluster_mgr模組會間隔N秒持續向每一個storage shard的主節點寫入心跳來探測其主節點的可用性。

如果發現某個storage shard（標記為 SS1）的主節點M0持續一定時間不能寫入，就會啟動下文描述的選主和主備切換流程。

M0如果重啟的足夠快那麼並不會引發主備切換，cluster_mgr會設定其可寫，從而M0可以繼續擔任主節點，否則，cluster_mgr就會啟動如下的選主和切換流程。

主節點選舉和切換

KunlunDB的Fullsync HA的主節點選舉和切換流程主要包括如下步驟：

1. 在SS1 的所有備機中找到含有最新relay log的備機M1作為候選主節點。

如果有多個最新備機則按照更詳細的規則選出最合適的備機作為M1。

KunlunDB的Fullsync機制確保了叢集有一個或者多個（fullsync_consistency_level) 備機一定含有所有已經向計算節點確認完成了提交的事務的binlog。

因此，KunlunDB可以忍受主節點和fullsync_consistency_level - 1個備節點同時當機的錯誤而不丟失已提交事務的資料。

1. 待M1的relay log重放完畢後，將M1提升為SS1的主節點。

MySQL-8.0具備了writeset事務依賴檢查機制（binlog_transaction_dependency_tracking=writeset或者writeset_session)，可以讓MySQL備機重放速度在replica_parallel_type=logical_clock時比mysql-5.7更快。通常情況下主備延遲都只有幾秒鐘。

但是如果使用者資料表設計和使用不合理，比如沒有定義主鍵和唯一索引的情況先執行大量行更新或者刪除語句（即使每個語句只改/刪了少量行），則會導致備機重放（replay）binlog的延時較大，在這種特殊情況下重放完畢所有的relay log需要消耗較長的時間，這段時間內任何備機無法提升為主節點。

為了避免此類特殊情況出現，我們為KunlunDB開發了非常便利的備機重做介面和備機延時告警機制，確保DBA可以及時收到備機延時過大的告警並且點一下按鈕就完成了備機重做從而再次緊緊跟上主節點的步伐。

1. 改變SS1的其他備機的主節點為M1

對於發生網路分割槽或者手動切換主節點的情況，如果舊的主節點M0 仍然可以寫入，即M0沒有發生當機或者重啟，那麼cluster_mgr會在提升M1為主節點之前，先把M0 降級為備節點，設定其為只讀狀態，防止發生腦裂。

1. 將“M1是SS1的主節點”這個事實告知所有計算節點，即更新它們的pg_shard.master_node_id欄位，這樣計算節點就可以及時獲知並寫入新主節點。

計算節點的主節點資訊不是最新的也無妨，我們對此有防禦手段。

首先，任何kunlun-storage節點啟動後都是隻讀狀態，所以如果M0因為任何原因重啟之後如果SS1已經完成了主備切換，那麼重啟之後M0無法被寫入，即使有一些計算節點的主節點資訊還沒有及時更新從而仍然試圖寫入M0，這些寫入操作也會失敗，因此不會發生腦裂。

當計算節點發現它所知道的主節點無法寫入時，如果此時cluster_mgr 還沒有更新計算節點的pg_shard.master_nodeid欄位，則計算節點會自動啟動主節點探測程式，找到SS1的新的主節點。

在找到新主之前，計算節點會根據系統設定決定阻塞等待新主選舉完成或者直接返回錯誤給客戶端。因此可以保障主節點故障對業務無感知。

1. 舊的主節點重新加入—閃回

如果舊主節點M0之後某個時間重新完成啟動，那麼cluster_mgr會把它作為備機重新加入SS1這個storage shard。

由於Fullsync機制使用after commit模式等待備機ACK，所以M0中可能有一些已經在M0本季提交但是沒有收到任何ACK的事務，這些事務都需要備閃回掉。

kunlun-storage的閃回外掛會在啟動後完成閃回，以確保隨後的備機複製可以正常執行。

閃回操作主要做的就是對於這些多餘的事務執行的行操作做相反的操作，將其改動去除掉，並且切除多餘的binlog檔案，並且從mysql.gtid_executed系統表中把那些被閃回的事務的gtid去掉。

最後，kunlun-storage FullsyncHA有一套實用的措施來避免在極端情況下產生不必要的主備切換。

這通常是在寫入負載極重的情況下容易發生，因此不必要的主備切換容易引起系統負載最重的情況下效能下降甚至短暫不可用，因而是需要極力避免的問題。

我們基於多年豐富的現網開發和運維經驗，以及對MySQL核心相關技術的深入理解，實現了一整套邏輯可以識別和避免不必要的主備切換。

通過分散式事務處理以及Fullsync和Fullsync HA機制，KunlunDB可以確保完備的資料一致性保障和容災能力，並實現了高可靠性和高可用性，同時也提供了極高的效能，可以勝任高併發重負載的OLTP場景。

END