專利名稱：一種基于事務重做的異構(gòu)集群多副本一致性維護方法
技術(shù)領(lǐng)域：
本發(fā)明屬于數(shù)據(jù)庫技術(shù)領(lǐng)域，尤其是一種基于事務重做的異構(gòu)集群多副本一致性維護方法。
背景技術(shù)：
基于分布式數(shù)據(jù)庫系統(tǒng)的大型企業(yè)應用越來越廣泛。為了提高系統(tǒng)可靠性，系統(tǒng)中的關(guān)鍵數(shù)據(jù)會在異地或本地保存多個副本，多個副本數(shù)據(jù)必須要保持一致性。一致性包括強一致性和弱一致性兩種，其中強一致性是要求數(shù)據(jù)任何時刻都是一致的，也就是數(shù)據(jù)的實時一致性；而弱一致性，不要求數(shù)據(jù)的實時一致，而是在達到一定條件下保證數(shù)據(jù)一致，也就是所謂的最終一致性。維護強一致性的代價相對較高，因此，一般都用在數(shù)據(jù)量較小的關(guān)鍵數(shù)據(jù)，而對于海量數(shù)據(jù)，為了系統(tǒng)可用性目的，一般都只要求數(shù)據(jù)的最終一致性。目前，幾乎所有的無共享集群都要求數(shù)據(jù)節(jié)點的完全同構(gòu)，但是，在實際應用中，企業(yè)往往會將關(guān)鍵的配置數(shù)據(jù)放在安全性和可靠性更高的高端商業(yè)數(shù)據(jù)庫中，而把海量的業(yè)務數(shù)據(jù)放在普通的中低端甚至開源數(shù)據(jù)庫中以節(jié)省成本，這就需要企業(yè)級集群解決方案支持異構(gòu)數(shù)據(jù)庫節(jié)點。而對于副本一致性維護，目前通用的方式主要有如下兩種方式:第一種方式是基于觸發(fā)器和語句分發(fā)的中間件方式，這是一種典型的利用中間件的方式，通過中間件把主數(shù)據(jù)節(jié)點上的操作同步或異步地發(fā)送給副本數(shù)據(jù)節(jié)點同樣的執(zhí)行一遍。該方式在同構(gòu)集群里可以一定程度上實現(xiàn)多副本維護功能，但是有明顯的缺陷:由于采用分布式的架構(gòu)，導致在集群層下發(fā)的語句順序和在數(shù)據(jù)節(jié)點上的實際執(zhí)行順序是不能保證一致的，因此這種方式必須在集群中間件層面進行DML語句的串行化，否則，將很可能會引發(fā)數(shù)據(jù)不一致，甚至整個集群僵死等嚴重問題。而這種在集群中間件層面進行的DML串行化，嚴格按照一條語句完成之后才能下發(fā)另一條語句的規(guī)則，導致整個集群退化為單用戶操作模式，并發(fā)性能無法容忍，同時又會導致副本一致性維護的代價呈線性倍數(shù)的提高，實用性不高。第二種方式是基于日志傳輸?shù)臄?shù)據(jù)庫復制方式。這是一種完全依靠節(jié)點數(shù)據(jù)庫自身進行一致性維護的方式，目前主流數(shù)據(jù)庫更多采用的是這種方式。這種方式通過主數(shù)據(jù)節(jié)點向副本數(shù)據(jù)節(jié)點傳輸binlog (二進制日志)，而副本數(shù)據(jù)節(jié)點分析日志并進行日志重做的方式實現(xiàn)。顯然這種方式僅適用于同構(gòu)數(shù)據(jù)庫集群的情況，因為異構(gòu)數(shù)據(jù)庫的日志格式勢必不同，無法通過日志重做進行多副本維護。

發(fā)明內(nèi)容
本發(fā)明的目的在于克服現(xiàn)有技術(shù)的不足，提供一種設(shè)計合理、性能穩(wěn)定且效率高的基于事務重做的異構(gòu)集群多副本一致性維護方法。本發(fā)明解決其技術(shù)問題是采取以下技術(shù)方案實現(xiàn)的:一種基于事務重做的異構(gòu)集群多副本一致性維護方法，包括以下階段:查詢執(zhí)行階段，該階段包括以下步驟:
步驟1:集群主數(shù)據(jù)節(jié)點事務管理模塊跟蹤活動事務表，錄制事務操作；步驟2:集群為主數(shù)據(jù)節(jié)點生成事務重做日志；步驟3:集群每隔一段時間將主數(shù)據(jù)節(jié)點的事務重做日志文件發(fā)送給所有副本數(shù)據(jù)節(jié)點，并管理節(jié)點狀態(tài)；副本維護階段，該階段包括以下步驟:副本數(shù)據(jù)節(jié)點不斷地接收來自于主數(shù)據(jù)節(jié)點的事務重做日志文件，并在收到之后給予確認收到的回復，接收到事務重做日志之后，副本數(shù)據(jù)節(jié)點按照日志中記錄的SQL語句的順序，嚴格串行化的執(zhí)行每條DML語句；故障恢復階段，該階段包括以下步驟:步驟1:數(shù)據(jù)庫管理員將主數(shù)據(jù)節(jié)點更改為只讀狀態(tài)；步驟2:從集群記錄的故障信息中查找出所有故障節(jié)點對應的存檔日志，依照存檔文件的順序逐個在故障節(jié)點上重做日志，直到所有副本數(shù)據(jù)節(jié)點的數(shù)據(jù)恢復到同主數(shù)據(jù)節(jié)點一致的狀態(tài)；步驟3:標志副本數(shù)據(jù)節(jié)點為可用狀態(tài)，并恢復主數(shù)據(jù)節(jié)點為讀寫狀態(tài)；而且，所述查詢執(zhí)行階段的步驟I的處理過程為:在存放主數(shù)據(jù)的節(jié)點數(shù)據(jù)庫事務管理模塊增加記錄事務涉及的語句的邏輯，生成活動事務表。而且，所述的活動事務由活動事務以及該活動事務所執(zhí)行的語句構(gòu)成，每個事務內(nèi)部的語句是按照從一定的順序依次記錄在該活動事務表中。而且，所述的活動事務表為Hash表，hash鍵是事務id，hash值是一個鏈表并按照語句順序記錄該事務的所有查詢語句。而且，所述查詢執(zhí)行階段的步驟2的處理過程為:當有事務提交時，從活動事務表中把該事務的所有DML語句鏈表取出，按順序記錄在事務重做日志中，并從活動事務表中刪除該事務以及該事務的所有操作語句；當事務被回滾時，從活動事務表中刪除該事務以及該事務的所有操作語句。而且，所述查詢執(zhí)行階段的步驟3管理節(jié)點狀態(tài)的方法為:集群向所有副本數(shù)據(jù)節(jié)點發(fā)送事務重做日志后，等待所有副本數(shù)據(jù)節(jié)點的回復以確認所有副本都已收到，如果所有副本數(shù)據(jù)節(jié)點都及時給出了響應，集群刪除已發(fā)送的日志；如果發(fā)現(xiàn)有的副本數(shù)據(jù)節(jié)點沒有及時給予響應，集群將該日志存檔，并記錄未回復的副本數(shù)據(jù)節(jié)點，同時將這些節(jié)點標志為不可用狀態(tài)，被標志為不可用狀態(tài)的節(jié)點將進入故障恢復階段。本發(fā)明的優(yōu)點和積極效果是:本發(fā)明利用基于語句分發(fā)中間件方式的語句重做技術(shù)和基于二進制日志傳輸?shù)娜罩局刈黾夹g(shù)兩種方式的優(yōu)勢，解決了基于語句分發(fā)中間件方式必須在集群層面進行DML串行化導致的代價高、性能差的問題，同時又彌補了二進制日志傳輸方式無法支持異構(gòu)數(shù)據(jù)庫的不足，在目前大數(shù)據(jù)領(lǐng)域普遍使用的無共享集群中實現(xiàn)多副本之間的快速一致性維護，保證無共享集群的高可用性，同時能夠支持集群數(shù)據(jù)庫節(jié)點的異構(gòu)化。


圖1是本發(fā)明的活動事務表結(jié)構(gòu)示意圖；圖2是活動事務處理流程圖；圖3是本發(fā)明的事務重做日志結(jié)構(gòu)示意圖4是重做后的活動事務表結(jié)構(gòu)示意圖。
具體實施例方式以下結(jié)合附圖對本發(fā)明做進一步詳述。一種基于事務重做的異構(gòu)集群多副本一致性維護方法是利用并發(fā)事務實際執(zhí)行順序是事務的提交順序這一原理，通過對主數(shù)據(jù)節(jié)點進行活動事務跟蹤，按照事務提交順序進行查詢錄制，將主數(shù)據(jù)節(jié)點錄制的按照事務提交順序組織的語句序列傳播到副本數(shù)據(jù)節(jié)點進行事務重做的方式。此方式可以保證副本數(shù)據(jù)和主數(shù)據(jù)在事務層面進行的邏輯操作完全一致，從而保證副本數(shù)據(jù)和主數(shù)據(jù)之間的最終一致性。由于錄制是發(fā)生在主數(shù)據(jù)節(jié)點的事務管理層，因此不會造成集群中間件本身的串行化處理，解決了集群的并發(fā)性問題；由于傳輸?shù)氖遣樵冋Z句，而且只需重做DML查詢，因此不僅系統(tǒng)負載輕，保證一致性維護的高性能；更為重要的是，這種事務重做方式基于標準的SQL，可以支持各種異構(gòu)數(shù)據(jù)庫。下面對本發(fā)明進行詳細說明:一種基于事務重做的異構(gòu)集群多副本一致性維護方法，包括如下階段:查詢執(zhí)行階段，該階段包括以下步驟:步驟1:集群事務管理模塊跟蹤活動事務表，錄制事務操作在查詢執(zhí)行階段，在存放主數(shù)據(jù)的節(jié)點數(shù)據(jù)庫的事務管理模塊增加記錄事務涉及的語句的邏輯，生成活動事務表。其具體流程:事務管理模塊在內(nèi)存中申請緩沖區(qū)，以Hash表的形式記錄所有活動事務正在執(zhí)行的語句。其中hash鍵是事務id,hash值是一個鏈表，按照語句順序記錄該事務的所有查詢語句，其中select語句不記錄。每當一個事務要執(zhí)行一條查詢的時候，如果是DML語句，則根據(jù)其事務id在hash表里查找，如果已有該事務則把DML按順序加在該事務語句鏈表的最后,如果沒有該事務則在hash表中新生成一個hash入口，并記錄該DML語句。通過上述處理建成的活動事務表結(jié)構(gòu)，如圖1所示，該結(jié)構(gòu)表明當前在數(shù)據(jù)庫的事務管理模塊有6個活動事務，分別是事務TX1、TX2、TX3、TX4、TX5、TX6。其中事務TX1、TX3、和TX6執(zhí)行了 DML語句。每個事務內(nèi)部的語句是按照從左至右的先后順序依次記錄在該活動事務hash表中的。步驟2:集群為主數(shù)據(jù)節(jié)點生成事務重做日志當有事務提交時,從hash表中把該事務的所有DML語句鏈表取出，按順序記錄在事務重做日志中，并從活動事務hash表中刪除該事務以及該事務的所有操作語句。而當事務被回滾的時候，則僅需從活動事務hash表中刪除該事務以及該事務的所有操作語句即可，而不必記錄事務重做日志。事務重做日志是集群為主數(shù)據(jù)節(jié)點生成和維護一個文件，語句逐條組織，按實際執(zhí)行順序記錄了主數(shù)據(jù)節(jié)點的所有DML語句。假設(shè)上述活動事務表中的六個事務的執(zhí)行順序如圖2所示，可以看出，事務TX6最后開始(Begin),但是最先提交(Commit)。而事務TXl先于所有事務Begin,但是晚于事務TX6提交(Commit)。因此，此時生成的事務重做日志如圖3所示，而此時更新的活動事務表結(jié)構(gòu)如圖4所示，可以看出，已經(jīng)提交(Commit)的事務以及該事務所進行的操作語句都被從活動事務表中剔除。步驟3:集群每隔一段時間將主數(shù)據(jù)節(jié)點的事務重做日志文件發(fā)送給所有副本數(shù)據(jù)節(jié)點，并管理節(jié)點狀態(tài)。事務重做日志的格式逐條組織，記錄了如圖3所示的主數(shù)據(jù)節(jié)點在事務管理模塊實際執(zhí)行DML語句的順序，語句逐行存儲在事務重做日志文件中。集群每隔一段時間把主數(shù)據(jù)節(jié)點的事務重做日志發(fā)送給所有副本數(shù)據(jù)節(jié)點，并等待所有副本數(shù)據(jù)節(jié)點的回復以確認所有副本都已收到。如果所有副本數(shù)據(jù)節(jié)點都及時給出了響應，集群刪除已發(fā)送的日志；如果發(fā)現(xiàn)有的副本數(shù)據(jù)節(jié)點沒有及時給予響應，集群將該日志存檔，并記錄未回復的副本數(shù)據(jù)節(jié)點，同時將這些節(jié)點標志為不可用狀態(tài)。被標志為不可用狀態(tài)的節(jié)點將進入故障恢復階段，需要人工進行數(shù)據(jù)一致性維護。副本維護階段，該階段的處理包括:副本數(shù)據(jù)節(jié)點不斷地接收來自于主數(shù)據(jù)節(jié)點的事務重做日志文件，并在收到之后給予確認收到的回復。副本數(shù)據(jù)節(jié)點接收到事務重做日志之后，副本數(shù)據(jù)節(jié)點按照日志中記錄的SQL語句的順序，嚴格串行化的執(zhí)行每條DML語句。這一過程是自動的，不需要人工參與，由集群調(diào)度副本數(shù)據(jù)節(jié)點自行完成數(shù)據(jù)一致性維護。故障恢復階段。如果在集群的自動調(diào)度下，副本數(shù)據(jù)節(jié)點未能完成數(shù)據(jù)的一致性同步，則副本數(shù)據(jù)會進入故障恢復階段，這一階段需要數(shù)據(jù)庫管理員(DBA)進行人工干預進行數(shù)據(jù)一致性維護。故障恢復階段包括以下步驟:步驟1:數(shù)據(jù)庫管理員(DBA)需要將主數(shù)據(jù)節(jié)點更改為只讀狀態(tài)，即主數(shù)據(jù)節(jié)點不再接受DML操作。這一過程是為了給主數(shù)據(jù)節(jié)點的數(shù)據(jù)打一個基線，所有副本數(shù)據(jù)都以此為基準恢復到一致狀態(tài)。步驟2:從集群記錄的故障信息中查找出所有故障節(jié)點對應的存檔日志，依照存檔文件的順序逐個在故障節(jié)點上重做日志，直到所有副本數(shù)據(jù)節(jié)點的數(shù)據(jù)恢復到同主數(shù)據(jù)節(jié)點一致的狀態(tài)。步驟3:標志副本數(shù)據(jù)節(jié)點為可用狀態(tài)，并恢復主數(shù)據(jù)節(jié)點為讀寫狀態(tài)，即主數(shù)據(jù)節(jié)點可以接受并處理DML語句。本發(fā)明的關(guān)鍵特點在于利用并發(fā)事務實際執(zhí)行順序是事務的提交順序這一原理，在主數(shù)據(jù)節(jié)點錄制事務執(zhí)行順序，而不是在集群中間件進行錄制，據(jù)此生成事務重做日志并通過網(wǎng)絡(luò)進行傳輸，在副本數(shù)據(jù)節(jié)點重做日志記錄的SQL語句，從而保證主數(shù)據(jù)和副本數(shù)據(jù)的最終一致性。此技術(shù)方案具有低負載、高性能、弱一致、支持異構(gòu)等特點。需要強調(diào)的是，本發(fā)明所述的實施例是說明性的，而不是限定性的，因此本發(fā)明包括并不限于具體實施方式
中所述的實施例，凡是由本領(lǐng)域技術(shù)人員根據(jù)本發(fā)明的技術(shù)方案得出的其他實施方式，同樣屬于本發(fā)明保護的范圍。
權(quán)利要求
1.一種基于事務重做的異構(gòu)集群多副本一致性維護方法，其特征在于:包括以下階段: 查詢執(zhí)行階段，該階段包括以下步驟: 步驟1:集群主數(shù)據(jù)節(jié)點的事務管理模塊跟蹤活動事務表，錄制事務操作； 步驟2:集群為主數(shù)據(jù)節(jié)點生成事務重做日志； 步驟3:集群每隔一段時間將主數(shù)據(jù)節(jié)點的事務重做日志文件發(fā)送給所有副本數(shù)據(jù)節(jié)點，并管理節(jié)點狀態(tài)； 副本維護階段，該階段包括以下步驟:副本數(shù)據(jù)節(jié)點不斷地接收來自于主數(shù)據(jù)節(jié)點的事務重做日志文件，并在收到之后給予確認收到的回復；接收到事務重做日志之后，副本數(shù)據(jù)節(jié)點按照日志中記錄的SQL語句的順序，嚴格串行化的執(zhí)行每條DML語句； 故障恢復階段，該階段包括以下步驟: 步驟1:數(shù)據(jù)庫管理員將主數(shù)據(jù)節(jié)點更改為只讀狀態(tài)； 步驟2:從集群記錄的故障信息中查找出所有故障節(jié)點對應的存檔日志，依照存檔文件的順序逐個在故障節(jié)點上重做日志，直到所有副本數(shù)據(jù)節(jié)點的數(shù)據(jù)恢復到同主數(shù)據(jù)節(jié)點一致的狀態(tài)； 步驟3:標志副本數(shù)據(jù)節(jié)點為可用狀態(tài)，并恢復主數(shù)據(jù)節(jié)點為讀寫狀態(tài)。
2.根據(jù)權(quán)利要求1所述的一種基于事務重做的異構(gòu)集群多副本一致性維護方法，其特征在于:所述查詢執(zhí)行階段的步驟I的處理過程為:在存放主數(shù)據(jù)的節(jié)點數(shù)據(jù)庫的事務管理模塊增加記錄事務涉及的語句的邏輯，生成活動事務表。
3.根據(jù)權(quán)利要求2所述的一種基于事務重做的異構(gòu)集群多副本一致性維護方法，其特征在于:所述的活動事務由活動事務以及該活動事務所執(zhí)行的語句構(gòu)成，每個事務內(nèi)部的語句是按照從一定的順序依次記錄在該活動事務表中。
4.根據(jù)權(quán)利要求3所述的一種基于事務重做的異構(gòu)集群多副本一致性維護方法，其特征在于:所述的活動事務表為Hash表,hash鍵是事務id,hash值是一個鏈表并按照語句順序記錄該事務的所有查詢語句。
5.根據(jù)權(quán)利要求1所述的一種基于事務重做的異構(gòu)集群多副本一致性維護方法，其特征在于:所述查詢執(zhí)行階段的步驟2的處理過程為:當有事務提交時，從活動事務表中把該事務的所有DML語句鏈表取出，按順序記錄在事務重做日志中，并從活動事務表中刪除該事務以及該事務的所有操作語句；當事務被回滾時，從活動事務表中刪除該事務以及該事務的所有操作語句。
6.根據(jù)權(quán)利要求1所述的一種基于事務重做的異構(gòu)集群多副本一致性維護方法，其特征在于:所述查詢執(zhí)行階段的步驟3管理節(jié)點狀態(tài)的方法為:集群向所有副本數(shù)據(jù)節(jié)點發(fā)送事務重做日志后，等待所有副本數(shù)據(jù)節(jié)點的回復以確認所有副本都已收到，如果所有副本數(shù)據(jù)節(jié)點都及時給出了響應，集群刪除已發(fā)送的日志；如果發(fā)現(xiàn)有的副本數(shù)據(jù)節(jié)點沒有及時給予響應，集群將該日志存檔，并記錄未回復的副本數(shù)據(jù)節(jié)點，同時將這些節(jié)點標志為不可用狀態(tài)，被標志為不可用狀態(tài)的節(jié)點將進入故障恢復階段。
全文摘要
本發(fā)明涉及一種基于事務重做的異構(gòu)集群多副本一致性維護方法，其特點是包括查詢執(zhí)行階段集群事務管理模塊跟蹤活動事務表，錄制事務操作；集群為主數(shù)據(jù)節(jié)點生成事務重做日志；集群將事務重做日志文件發(fā)送給所有副本數(shù)據(jù)節(jié)點并管理節(jié)點狀態(tài)；副本維護階段副本數(shù)據(jù)節(jié)點接收來自于主數(shù)據(jù)節(jié)點的事務重做日志文件；故障恢復階段數(shù)據(jù)庫管理員將查找出故障節(jié)點對應的存檔日志，將所有副本數(shù)據(jù)節(jié)點的數(shù)據(jù)恢復到同主數(shù)據(jù)節(jié)點一致的狀態(tài)。本發(fā)明解決了現(xiàn)有技術(shù)存在代價高、性能差的問題，彌補了二進制日志傳輸方式無法支持異構(gòu)數(shù)據(jù)庫的不足，實現(xiàn)了多副本之間的快速一致性維護，保證無共享集群的高可用性，同時能夠支持集群數(shù)據(jù)庫節(jié)點的異構(gòu)化。
文檔編號G06F11/34GK103198159SQ20131015333
公開日2013年7月10日 申請日期2013年4月27日 優(yōu)先權(quán)日2013年4月27日
發(fā)明者王洋, 楊海成, 李陽, 馮柯, 蔣志勇, 蔣旭, 陳東, 譚煒波, 孫磊, 劉勇生, 李曉鵬, 劉榮 申請人:國家計算機網(wǎng)絡(luò)與信息安全管理中心, 天津神舟通用數(shù)據(jù)技術(shù)有限公司