「分散式技術專題」故障恢復

Hubble資料庫發表於2023-02-14

由資料庫管理系統提供一套方法,可及時發現故障和修復故障,從而防止資料被破壞。資料庫系統能儘快恢復資料庫系統執行時出現的故障,可能是物理上或是邏輯上的錯誤。比如對系統的誤操作造成的資料錯誤等。

原理

隨著計算機網路技術的日臻成熟,分散式資料庫以其較高的訪問區域性效能逐漸成為關係企業的主流資料庫系統。其中恢復子系統是分散式資料庫系統的關鍵性組成部分,其在資料庫的故障恢復中發揮著至關重要的作用。在分散式資料庫特點分析的基礎上,對資料庫故障恢復技術進行了剖析,基於兩階段及三階段協議的資料庫恢復方法,從而提高了資料庫系統的可用性。

實現方式

故障恢復協議

分散式資料庫系統中的事務需要跨結點執行,因此回覆故障時需要故障恢復協議協調不同子事物之間的關係,以保證分佈在不同節點上子事務進行相同的捲回或提交操作。當前分散式資料庫系統恢復協議包括兩階段和三階段提交協議兩種,主要介紹兩階段提交協議。

兩階段提交協議的要點:

允許參與者單方面撤銷事務,直到做出肯定性建議;
一旦參與者確定了提交或者撤銷建議,不能再更改;
當參與者處於就緒狀態,她可根據協調者發出的訊息的種類,轉換為相應的提交或者撤銷狀態;
協調者依據全域性提交規則做出全域性終結決定;
在發生故障的情況下,協調者和參與者可能會進入互相等待的狀態,一般採用定時器來解決這種問題。

故障轉移協議

故障轉移協議使用以解決分割槽伺服器節點故障後,資料分割槽轉移導致資料本地化率降低的問題。為實現上述目的, Hubble的方案包括一種基於分散式叢集的資料處理方法。

處理方法簡介:

同一個資料分割槽下的所有資料塊的各個備份資料中,以資料分割槽為單位,第一個備份資料儲存在所在的資料節點內,其他各備份資料分別儲存在其他資料節點中資料分割槽最少的兩個資料節點內,分別稱為第一備份節點和第二備份節點;當資料分割槽伺服器發生當機或不提供服務時,轉移資料分割槽到第一備份節點和第二備份節點中資料分割槽較少的資料節點內。
首先,除了第一個備份資料儲存在所在的資料節點內,其他各備份資料分別儲存在其他資料節點中資料分割槽最少的兩個資料節點內,把資料分割槽中各備份資料完整不發散地對應儲存在不同的資料節點上,能夠在發生故障轉移之後各節點的資料負載儘量均衡。
並且,當資料分割槽伺服器發生當機或不提供服務時,轉移資料分割槽到第一備份節點和第二備份節點中資料分割槽較少的資料節點內,即選擇其中一個資料分割槽較少的節點作為遷移目標,保證遷移之後本地化率仍然為 1,在發生節點故障導致分割槽轉移後,為轉移後的分割槽提供服務的分割槽伺服器仍從本地獲取資料,而不從透過網路從其他節點獲取資料,實現資料分割槽不透過網路仍能訪問資料,提高分割槽伺服器節點故障後的分散式資料庫的訪問效率,解決了分散式資料庫除了主壓縮方法以外缺乏提高本地化率手段的問題。
在資料分割槽轉移之後,在沒有當前資料分割槽備份資料的各資料節點中找到資料分割槽最少的資料節點,作為補全目標節點,以資料分割槽為單位將當前資料分割槽的所有資料塊的備份資料儲存到所述補全目標節點內。如果在其他資料節點中找不到資料分割槽最少的兩個資料節點,那麼,在其他資料節點中隨機選擇兩個資料節點。

具體實施方式

通常情況下,各資料塊具有三個備份資料,因此,本實施例以三個備份資料為例。其中,副本是指備份資料檔案,首個副本指第一個備份資料,第二個副本指第二個備份資料,第三個副本指第三個備份資料。在底層分散式檔案系統儲存上,根據分散式資料庫的實際需求,重新定義了一種新的塊備份規則:同一個資料分割槽下的所有資料塊的三份備份資料以資料分割槽為單位完整不發散地儲存到三個資料節點上。所以,同一個資料分割槽下的所有資料塊的各個備份資料中,以資料分割槽為單位,第一個備份資料儲存在該資料分割槽所在的資料節點內。除了該資料分割槽所在的資料節點的其他資料節點中,找到資料分割槽最少的兩個資料節點,將這兩個資料節點稱為第一備份節點和第二備份節點,那麼,其他各備份資料,即第二個備份資料和第三個備份資料分別儲存在第一備份節點和第二備份節點內。
以資料分割槽為單位的含義為:同屬於一個資料分割槽的所有的資料塊的第一個備份資料作為一個整體,儲存在該資料分割槽所在的資料節點內;同屬於一個資料分割槽的所有的資料塊的第二個備份資料和第三個備份資料也分別作為一個整體,分別儲存在第一備份節點和第二備份節點內。另外,如果在其他資料節點中找不到資料分割槽最少的兩個資料節點,那麼,只有在這些其他資料節點中隨機選擇兩個資料節點作為第一備份節點和第二備份節點。因此,分散式檔案系統上的資料的三個備份資料儲存到所有資料節點中資料分割槽較少的節點上,在發生故障轉移之後各資料節點的資料負載能夠儘量均衡。當資料分割槽伺服器發生當機或不提供服務時,在其他兩個完整備份的節點中,即在第一備份節點和第二備份節點中選擇一個資料分割槽較少的資料節點,作為遷移目標。轉移資料分割槽到第一備份節點和第二備份節點中資料分割槽較少的資料節點內。由於第一備份節點和第二備份節點中資料分割槽較少的資料節點上儲存有完整的資料分割槽檔案,則本地化率保持為 1,因此,這種處理方式能夠保證遷移之後本地化率仍然為1,實現資料分割槽不透過網路仍能訪問資料,提高資料訪問效率,解決了分散式資料庫除了主壓縮方法以外缺乏提高本地化率手段的問題。進一步地,在資料分割槽轉移之後,在沒有當前資料分割槽備份資料的各資料節點中找到資料分割槽最少的資料節點,作為補全目標節點,以資料分割槽為單位將當前資料分割槽的所有資料塊的備份資料儲存到補全目標節點內。
上述過程為損失資料塊補全的過程,所補全的塊的備份以資料分割槽為單位完整的儲存在所選擇的補全目標節點上。

資料恢復

事務日誌

事務日誌是一個與資料庫檔案分開的檔案。它儲存對資料庫進行的所有更改,並全部記錄插入、更新、刪除、提交、回退和資料庫模式的變化。事務日誌還稱作前滾日誌或重做日誌。事務日誌是備份和恢復的重要元件。針對資料庫改變所做的記錄,記錄對資料庫的任何操作,將記錄結果儲存在獨立的檔案中。建立日誌檔案,備份副本 +日誌檔案綜合起來才能有效的恢復資料庫。並遵循“先寫日誌檔案,然後再寫資料庫的修改”。

基於檢查點的故障恢復技術

由於事務所具有的原子性,使得事務一旦出現故障就必須從頭開始執行,因而也存在許多缺點。比如,一個事務是一個長時事務,那麼出現事務故障時,重新啟動事務執行會造成許多重複和浪費;再比如,如果不是由於系統內部的原因引起的故障,系統重啟後應該可以從中斷處繼續執行,這樣才能提高恢復效率。為此,一般採用檢查點方法,其思想是;在某一時刻將駐留在記憶體中的資料寫到資料庫,避免系統停機等故障造成的損失,以利於事物的恢復執行。在資料庫中,檢查點分為兩種:系統檢查點和事務檢查點,系統週期檢查的時刻稱為系統檢查點。事務檢查點指使用者可以在事務中設定檢查點,要求系統記錄事務的狀態。由於檢查點記錄內容繁複,系統在記錄當前檢查點記錄時,一般要覆蓋上一檢查點記錄,以避免大量檢查點記錄造成的空間浪費。一旦系統需要恢復資料庫狀態,就可以根據最新的檢查點資訊,從檢查點時刻開始執行,而不需要從頭開始那些被中斷的事務。由於在檢查點外要進行頻繁的記錄操作,過多的設立檢查點意味著增加更多的系統開銷,故應權衡利弊,選擇最佳的檢查點區間。檢查點記錄的資訊一般包括:所有活動事務;每個事務的最近日誌記錄的地址;在重新啟動事務時,獲得最近檢查點記錄的地址,從日誌中找到該檢查點記錄的內容,透過日誌進行查詢,就能決定哪些事務應重做,哪些事務應撤銷。這種方法需要定期或不定期地建立檢查點,儲存資料庫狀態。

優勢與劣勢

優勢

唯一可以從事務日誌中清除舊事務的策略。

備份非常快。

是唯一提供時間點恢復功能的備份和恢復策略。

劣勢

恢復過程比較慢。

面臨挑戰

由於造成資料庫故障原因較多,要應對多種原因的故障容錯,涉及的技術設計比較複雜,需要一個長期不斷完善的過程。


以上為故障恢復, 「分散式技術專題」是國產資料庫 hubble 團隊精心整編,專題會持續更新,歡迎大家保持關注。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70026685/viewspace-2935130/,如需轉載,請註明出處,否則將追究法律責任。

相關文章