eXtremeDB HA 運行時數據的同步方式

今天這篇文章主要是講述eXtremeDB HA 在工作的時候,主備機的數據同步策略。在介紹eXtremeDB的同步策略之前,先對HA系統做個簡單的說明,以及介紹一下傳統的高可用性的機制,以及高可用性(HA)之間同步的常見方式。
HA(High Available), 高可用性羣集,是保證業務連續性的有效解決方案,一般有兩個或兩個以上的節點,且分爲活動節點及備用節點。通常把正在執行業務的稱爲活動節點,而作爲活動節點的一個備份的則稱爲備用節點。當活動節點出現問題,導致正在運行的業務(任務)不能正常運行時,備用節點此時就會偵測到,並立即接續活動節點來執行業務。從而實現業務的不中斷或短暫中斷。
比如在網絡中的IP路由器,使用內存數據庫管理它們的路由表。比如飛行控制器,比如工業控制等。在這些行業的系統中,要求有非常可靠的事故處理和數據存儲。
爲了達到這些高可用性,傳統做法是數據庫通常會提供一種管理多個數據拷貝的方式。以這種方式實現的高可用性叫做Database Replication。在這種方式中,故障處理程序允許系統繼續故障發生時使用數據庫。這種方式如下圖所示:


如上圖所示,在這種模式下,數據庫的事務會被複制到備節點中(replica node or secondary node),而複製事務到備節點的節點叫主節點(master node or primary node)。那麼,數據庫的更新從主節點到備節點的傳導就是通過數據庫的事務完成的。
那麼根據備節點的更新是在主節點事務外完成還是主節點事務內完成,我們可以將這種數據庫主備節點間的同步方式分爲同步(eager or synchronous)和異步(lazy or asynchronous)。
在主節點事務外完成方式叫做異步,在主節點事務內完成叫做同步。
在同步方式中,以直截了當的方式提供主備節點中數據庫一致性。在這種方式下,沒有事務的丟失,當故障發生時,可以提供最快速的恢復,沒有同步的花銷。但是,這種方式,在正常主備節點正常工作的情況下,會增加進程的開銷和通信開銷,並且會延遲數據庫的應答時間。這種方式的工作流程如下圖所示:

與同步的方式相反,在Lazy模式下主備節點間的同步採用異步的方式。在這種方式下,主節點先提交更新的事務,然後在將更新事務發送到備節點。這種方式與同步相比,它可以提高數據庫的應答時間,但是,與此同時,存在一定的風險,比如當主節點將更新事務向備節點發送時,主節點出現故障,那麼數據庫的更新會丟失。應用還可能從備節點中讀到過期的數據,因爲更新事務在主節點已經完成,還沒來得及在備節點中提交。異步方式的工作流程如下如所示:

在面對網絡的不確定因素時,爲了提高可以預測的故障切換和應答時間,時間同步認知複製協議(time-cognizant eager replication protocols)被使用在了主備機之間的同步。在嵌入式系統和實時系統中,經常給進程設置了嚴格的執行時間,time-cognizant方式可以保證事務可以在主備節點間及時遞送。這種方式正如同步方式一樣,故障切換時間是非常短的。這種方式的工作流程如下圖所示:

在eXtremeDB HA組件中,在主備節點數據同步時,提供了同步和異步兩種方式。

       在eXtremeDB HA的同步方式中,採用的是一種基於時間認知兩階段提交的協議。這種模式在eXtremeDBHA 中是默認的方式。它的工作方式如下圖所示:


在eXtremeDB的HA中,也提供異步同步方式。在這種方式下,更新事務會先在主節點中執行,當主節點中的事務提交後,然後再將事務傳播到備節點中。這樣的優缺點正如上面說到的那樣,可以提供更快速的應答,但存在丟失事務,讀到過期數據的風險。它的工作流程如下圖所示:



發佈了26 篇原創文章 · 獲贊 0 · 訪問量 1萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章