元數據管理方法及管理系統的制作方法
【專利摘要】本發明提供了一種高可用性的元數據管理方法，包括步驟：在需要對元數據進行操作時，同時在至少兩個元數據庫上執行相同的元數據操作指令；其特征在于，當其中至少一個元數據庫上的操作完成時，則判定元數據操作成功。本發明還提供了一種高可用性的元數據管理系統。本發明有效避免了數據同步問題和單一主服務器的效率瓶頸問題。
【專利說明】元數據管理方法及管理系統
【技術領域】
[0001]本發明涉及一種元數據管理方法及管理系統。
【背景技術】
[0002]元數據是對數據資源的描述，英文名稱是“Metadata”，通常被解釋為data aboutdata，即關于數據的數據。元數據是信息共享和交換的基礎和前提，用于描述數據集的內容、質量、表示方式、空間參考、管理方式以及數據集的其他特征。
[0003]隨著信息技術不斷發展，以及人們對信息共享的迫切需求，元數據技術被應用于更多的領域，如:在圖書館與信息界，元數據被定為提供關于信息資源或數據的一種結構化的數據，是對信息資源的結構化的描述；在數據倉庫領域中，元數據被定義為描述數據及其環境的數據；在軟件構造領域，元數據被定義為在程序中不是被加工的對象，而是通過其值的改變來改變程序的行為的數據。
[0004]元數據往往是一個系統的基礎數據，在系統運行過程中，需要實時訪問元數據，以便對當前操作作出決策。元數據對整體服務有著十分關鍵的作用，其效率和容錯性直接關系到整個系統的訪問性能和可用性，因此元數據的高可用技術具有重要意義。
[0005]過去對元數據服務的可用性保證大都采用日志技術，而日志技術由于其自身的局限性，并不能很好地為元數據服務提供有力保障。逐步發展起集中式的元數據管理，即由一個單獨的節點服務器管理全部的元數據，具有控制簡單，設計，實現難度小等優點。但是，其缺點也是致命的:元數據庫是單一失效點。
[0006]針對這種情況，出現了一種雙元服務器的高可用系統。現在一般的雙元數據庫系統，一般為主從服務器，即主服務器，從服務器之間用內部網絡連接，組成活動/備用節點集群模型。這種模型可以使主元數據庫在節點失效的情況下，使從服務器接替主服務器的工作，達到不中斷服務，實現高可用的連續服務。
[0007]但是，這種服務模型在主節點失效時，需要通過基于日志和內存的同步方式，以及從服務器的非對稱服務結構達到高可用。如果從服務器還未完成同步也失效，將導致數據丟失這種嚴重的錯誤。并且，主從模式只能有一個提供服務，主服務器的效率將是瓶頸。
【發明內容】
[0008]本發明針對上述問題，提出了一種高可用性的元數據管理方法及管理系統，其有效避免了數據同步問題和單一主服務器的效率瓶頸問題。
[0009]在一個方面，本發明提供了一種元數據管理方法，包括步驟:
[0010]在需要對元數據進行操作時，同時在至少兩個元數據庫上執行相同的元數據操作指令；
[0011]其特征在于，當其中至少一個元數據庫上的操作完成時，則判定元數據操作成功。
[0012]在另一個方面，本發明提供了一種元數據管理系統，其特征在于，包括，
[0013]元數據操作單元，用于在需要對元數據進行操作時，同時在至少兩個元數據庫上執行相同的元數據操作指令；和
[0014]操作成功判斷單元，用于當其中至少一個元數據庫上的操作完成時，判定元數據操作成功。
[0015]本發明采用了元數據雙寫模式，有效避免了數據同步中發生錯誤的問題，并且兩個元數據地位是相等的，解決了單一主服務器的效率瓶頸問題。
【專利附圖】
【附圖說明】
[0016]下面將參照附圖描述本發明的具體實施例，其中:
[0017]圖1是本發明一個應用場景中的元數據管理系統的示意圖；
[0018]圖2是本發明的元數據庫管理方法的操作流程圖；
[0019]圖3是本發明的元數據庫管理系統的示意圖；
[0020]圖4是本發明的元數據庫的5種狀態的相互關系示意圖；
[0021]圖5是本發明的元數據庫的狀態轉換流程圖；
[0022]圖6是本發明的元數據庫租賃線程的流程圖；并且
[0023]圖7是本發明的元數據庫續租線程的流程圖。
【具體實施方式】
[0024]為了使本發明的技術方案及優點更加清楚明白，以下結合附圖對本發明的示例性實施例進行進一步詳細的說明，顯然，所描述的實施例僅是本發明的一部分實施例，而不是所有實施例的窮舉。
[0025]如圖1所示，在這個場景中，具有兩個元數據庫103和104，它們在整個網絡中處于同等的地位。這兩個元數據庫103和104通過路由器102與業務服務器101連接。該業務服務器101中運行著數量不定的服務進程，該業務服務器101將使用本地文件系統創建一些共享內存空間做交換數據之用。
[0026]本領域技術人員很容易理解到，盡管圖1中僅示出了一個業務服務器，但實際上并不限于一個業務服務器，可以是多個業務服務器連接至這兩個元數據庫103和104。同樣地，盡管圖1中示出了兩個元數據庫103和104，但實際上并不限于兩個，也可以是更多個元數據庫。在本說明書中，具體的數量僅是舉例。
[0027]這兩個元數據庫103和104在系統運行中，將采用雙寫模式向業務服務器101提供服務。雙寫模式在這里意思是，當需要對元數據進行操作時，需要對兩個元數據庫103和104同時操作。而且，只要有其中一個的操作完成，就認為元數據操作成功。如果有一個元數據庫操作失敗，需要將當前元數據操作指令保存到操作成功的元數據庫中，待操作失敗的元數據庫恢復有效后，再執行需要恢復的元數據操作指令，然后該元數據庫可繼續提供服務。具體地，若其中某個元數據庫(比如103)失效，另外一個元數據庫(比如104)將繼續提供服務，并保存失效元數據庫103需要恢復的元數據操作指令，待失效元數據庫103恢復有效后，再執行需要恢復的元數據操作指令，然后元數據庫103可繼續提供服務。
[0028]本發明提供了一種元數據庫管理方法，如圖2所示，其包括如下步驟:
[0029]在步驟S101，當需要對元數據進行操作時，在兩個元數據庫上同時執行修改元數據的操作。[0030]然后，在步驟S102，判斷兩個元數據庫是否均修改成功。如果均修改成功，則返回修改元數據成功(S1021)，流程結束。如果并未都修改成功，則繼續在步驟S103，判斷兩個元數據庫是否均修改失敗。如果均修改失敗，則返回修改元數據失敗(S1031)，流程結束。如果也并未都修改失敗，也就是說，一個元數據庫修改成功，而另一個元數據庫修改失敗，則流程轉到步驟S104。
[0031]在步驟S104，在業務服務器的本地文件系統中將操作失敗的元數據庫設置為不可用狀態，以免繼續向其發出修改指令。接著，在步驟S105中，在操作成功的元數據庫中記錄該操作失敗的數據庫上尚未執行的修改操作指令，以便后續再次執行。
[0032]接著,在步驟S106中，判斷上述記錄是否成功。如果未記錄成功,則將需要記錄的操作失敗的元數據庫的修改操作指令記錄在本地文件系統中(S1061)，以便后續再次執行。在本地文件系統中的記錄操作可采用獨占鎖的方式記錄。在記錄成功(不管是在成功元數據庫中記錄，還是在本地文件系統中記錄)后，則返回修改元數據成功(步驟S107)，流程結束。
[0033]基于同一發明構思，本發明提供了一種元數據管理系統200，如圖3所示，其包括:元數據操作單元201，用于在需要對元數據進行操作時，同時在至少兩個元數據庫103和104上執行相同的元數據操作指令；和操作成功判斷單元202，用于當其中至少一個元數據庫(比如104)上的操作完成時，判定元數據操作成功。
[0034]元數據管理系統200還可包括:操作恢復單元203，用于在有元數據庫(比如103)操作失敗時，將元數據操作指令保存到操作成功的元數據庫(比如104)中，待該操作失敗的元數據庫(比如103)恢復后再執行元數據操作指令。操作恢復單元203還可用于在保存失敗時將操作指令保存到發出操作指令的業務服務器101的本地文件系統中。操作恢復單元203還可用于在操作失敗的元數據庫(比如103)的恢復中，由租賃該元數據庫(比如103)成功的業務進程對該元數據庫(比如103)進行恢復操作。元數據庫的恢復和租賃將在后面詳細描述。
[0035]為了確保操作成功，元數據庫應具有如下5種狀態，這5種狀態的相互關系如圖4所示:
[0036]1、不可用狀態:元元數據庫的網絡不通，業務服務器不能連接到該元數據庫。
[0037]2、需要恢復狀態:元數據庫可以連接，但是，需要執行完恢復命令。
[0038]3、正在恢復狀態:元數據庫正在執行恢復命令，正在恢復。
[0039]4、完成恢復狀態:元數據庫現有恢復命令已經執行完成。但是，需要再次確認在恢復完成時是否有新的命令需要恢復。如果有新的命令需要恢復，則進入需要恢復狀態。如果無新的命令需要恢復，則進入可用狀態。
[0040]5、可用狀態:元數據庫已經完成了恢復操作，可以提供服務。
[0041]當業務服務器需要操作元數據庫時，首先，應該確定是否有一個元數據庫處于可用狀態。只要某一個元數據庫是可用狀態時，就能進行元數據的操作，否則，只能先試圖恢復其中一個元數據庫為可用狀態。
[0042]元數據庫的以上各個狀態之間的相互轉換流程如圖5所示。
[0043]首先，在步驟S201，判斷本元數據庫是否連接成功。如果連接不成功，則返回本元數據庫為不可用狀態(S2011)，結束。如果連接成功，則在本地文件中查看本元數據庫的狀態(S202)，判斷是否為可用狀態(S203)。
[0044]如果處于可用狀態，則返回本元數據庫為可用狀態(S2031)，結束。如果處于不可用狀態，則連接另一元數據庫。
[0045]在步驟204，判斷另一元數據庫是否連接成功。如果連接不成功，則將本元數據庫設置為需要恢復狀態(S2041)，結束。如果連接成功，則將本元數據庫設置為正在恢復狀態(S205)。
[0046]接著，在步驟S206，執行另一元數據庫或本地文件系統上的對本元數據庫的恢復命令。
[0047]然后，在步驟S207，判斷恢復命令是否執行成功。如果執行不成功，返回到步驟S204。如果執行成功，則接著在步驟S208，將本元數據庫設置為完成恢復狀態。
[0048]然后，在步驟S209，確認本元數據庫是否有需要恢復的命令。如果還有需要恢復的命令，返回到步驟S204。如果沒有需要恢復的命令，則流程進行到步驟S210，將本元數據庫設置為可用狀態。
[0049]最后，在步驟S211，如果接收到其他進程的狀態更改通知，則按照通知更改成相應的狀態(通常更改成不可用狀態)，結束。
[0050]在系統實際運行中，可能會出現各種運行錯誤，因此容錯是必須解決的問題。本發明的解決方案提供了完善的容錯機制。
[0051]常見的典型錯誤包括:其中一個元數據庫不可用；在修改元數據時兩個元數據庫相繼不可用；業務進程退出。容錯處理的流程可參見圖2所示的元數據庫雙寫模式的操作流程。
[0052]下面將針對上述各種情況詳細說明本發明的容錯處理機制。
[0053](I)其中一個元數據庫不可用
[0054]當系統在運行時，如果其中某個元數據庫不可用時，將會被業務服務器上的各個業務進程實時檢測到，此時該元數據庫將被設置為不可用狀態。如果當前沒有修改元數據的操作，元數據庫變為不可用，直接進入到元數據庫狀態轉換流程即可。如果當前正在修改元數據，需要先將該元數據庫修改元數據的操作保存到另一臺可用的元數據庫中，再進入元數據庫狀態轉換流程。
[0055](2)修改元數據時兩個元數據庫相繼不可用
[0056]如上所述，當修改元數據時，如果某個元數據庫不可用，需要將修改元數據的操作保存到另一臺可用的元數據庫中。但是，如果該可用的元數據庫突然變得不可用，那么需要保存的元數據修改操作將會保存失敗。此時，需要將修改元數據的操作保存到本地文件系統。
[0057](3)業務進程退出
[0058]當業務進程在運行過程中，終止運行。此時，需要恢復的元數據操作已經記錄到本地文件系統或元數據庫中。如果還沒有將需要恢復的元數據操作保存該業務進程就終止運行，將會發生丟失數據的嚴重錯誤。因此，用戶不能隨意將業務進程強制終止，除非用戶很清楚將發生什么情況。不過，其他的業務進程將繼續工作，不會受到影響。
[0059]如上所述，在本發明中，業務進程可能有多個，它們都能連接到這兩個元數據庫。如果某個元數據庫需要恢復，它們都能探測到該信息，并且都會試圖去恢復該元數據庫。但是，如果多個進程都同時恢復一個元數據庫，將會導致沖突。因此，需要有一種機制去保證它們的互斥性。為此，本發明采用了元數據庫租賃機制。也就是，只有成功租賃到某個元數據庫的業務進程，才有權對該元數據庫進行恢復操作。
[0060]下面，詳細描述元數據庫的租賃機制。
[0061]元數據庫的租賃機制，需要兩個線程合作完成，分別是元數據庫租賃線程和元數據庫續租線程，這兩個線程的流程圖分別如圖6和7示。
[0062]圖6示出了元數據庫的租賃機制。首先，在步驟S301，連接到元數據庫查看該元數據庫的租賃到期時間，判斷是否已到期。若已到期，則設置該元數據庫的新的租賃到期時間，通常為當前時間之后的某一時間，并將租賃者設置為本進程標識。上述操作必須在一個原子操作內完成。
[0063]隨后，在步驟S302，判斷上述租賃操作是否成功。若不成功，則結束。若租賃成功，則進行到步驟S303，通知續租線程保持續租。
[0064]接著，在步驟S304，獲取并執行全部恢復操作。這個恢復操作的過程可能會比較長。
[0065]在恢復過程結束(S305)后，通知續租線程續租結束(S306)。恢復操作全部執行成功或某個操作命令執行失敗，均將導致整個恢復操作過程結束。
[0066]圖7示出了元數據庫的續租機制。首先，在步驟S401接收到續租開始命令后，在步驟402確認是否收到續租結束命令。如果接收到續租結束命令，則返回到步驟S401。如果未接收到續租結束命令，則在步驟S403檢查是否已經到達續租啟動時刻(續租啟動時刻指的是應該啟動續租操作的時刻，比如租賃時間已過去一定比例，比如4/5)，如果已經到達，則修改元數據庫的續租信息，將租賃到期時間延長(S404)，如果未到達，則返回到步驟S402。
[0067]舉例來說，初始時，某一元數據庫還沒有被租賃，那么其“租賃到期時間”和“租賃者”為空。比如，后續某一時刻，該元數據庫被租賃，租賃時長為20秒，則設置“租賃到期時間”和“租賃者”，租賃到期時間為當前時刻加上20秒(T+20)。此后，如果有新的租賃請求則將被拒絕。在設定的續租啟動時刻，比如離租賃到期時間還差20*1/5 = 4秒，即T+16秒時，延長租賃時間，繼續租賃20秒。在T+36秒時刻，租賃時間結束，清空“租賃到期時間”和“租賃者”。此后，該元數據庫可響應于新的租賃請求。
[0068]很顯然，上述僅是舉例，續租啟動時刻并不限制于到達租賃到期時間的4/5，租賃時間也不限于20秒，而是可以根據實際情況靈活設置。
[0069]如上所述，本發明提供了一種高可用性的元數據庫管理方法及管理系統，解決了現在方案存在的幾個問題。
[0070](I)有效避免了數據同步問題。在主從式元數據庫模式中，需要將主服務器的數據同步到從服務器中，這種方式在同步過程中容易發生錯誤。而且，同步過程中，不能提供服務。本發明提供的解決方案避免了這個問題。
[0071](2)有效避免了單一主服務器的效率瓶頸問題。在主從式元數據庫模式中，始終只有一臺服務器對外提供服務。而在本解決方案中，兩個元數據庫的地位是相等的，均可以對外提供服務，只要有其中一個元數據庫執行成功就可返回。因此，不需要將全部的操作都放到一個主服務器上。[0072]以上實施例僅用以說明本發明的技術方案，而非對其進行限制。因此，在不背離本發明的精神及其實質的情況下，本領域技術人員可作出各種改變、替換和變型。很顯然，但這些改變、替換和變型都應涵蓋于本發明權利要求的保護范圍之內。
【權利要求】
1.一種元數據管理方法，包括步驟: 在需要對元數據進行操作時，同時在至少兩個元數據庫上執行相同的元數據操作指令； 其特征在于，當其中至少一個元數據庫上的操作完成時，則判定元數據操作成功。
2.如權利要求1所述的元數據管理方法，其特征在于，如果有元數據庫操作失敗，則將所述元數據操作指令保存到操作成功的元數據庫中，待該操作失敗的元數據庫恢復后再執行所述元數據操作指令。
3.如權利要求2所述的元數據管理方法，其特征在于，將操作失敗的元數據庫設置為不可用狀態。
4.如權利要求2所述的元數據管理方法，其特征在于，如果所述保存失敗，將所述元數據操作指令保存到發出元數據操作指令的業務服務器的本地文件系統中。
5.如權利要求2所述的元數據管理方法，其特征在于，在恢復所述操作失敗的元數據庫時，由租賃該元數據庫成功的業務進程對該元數據庫進行恢復操作。
6.如權利要求5所述的元數據管理方法，其特征在于，由租賃該元數據庫成功的業務進程對該元數據庫進行恢復操作具體為: 在判斷所述操作失敗的元數據庫的租賃到期時間已到達后，設置新的租賃到期時間，并將租賃者設置為所述業務進程； 在租賃成功后，通知續租線程保持續租； 執行恢復操作； 在恢復操作完成后，通知續租線程結束續租。
7.如權利要求6所述的元數據管理方法，其特征在于，所述續租線程的操作具體為: 在接收到續租開始命令后，確認是否收到續租結束命令； 如果未接收到續租結束命令，檢查是否已經到達續租啟動時刻； 在已經到達續租啟動時刻后，將租賃到期時間延長。
8.—種元數據管理系統，其特征在于，包括， 元數據操作單元，用于在需要對元數據進行操作時，同時在至少兩個元數據庫上執行相同的元數據操作指令；和 操作成功判斷單元，用于當其中至少一個元數據庫上的操作完成時，判定元數據操作成功。
9.如權利要求8所述的元數據管理系統，其特征在于，還包括: 操作恢復單元，用于在有元數據庫操作失敗時，將所述元數據操作指令保存到操作成功的元數據庫中，待該操作失敗的元數據庫恢復后再執行所述元數據操作指令。
10.如權利要求9所述的元數據管理系統，其特征在于，操作恢復單元還用于在所述保存失敗時將所述元數據操作指令保存到發出元數據操作指令的業務服務器的本地文件系統中。
11.如權利要求9所述的元數據管理系統，其特征在于，操作恢復單元還用于在恢復所述操作失敗的元數據庫時，由租賃該元數據庫成功的業務進程對該元數據庫進行恢復操作。
【文檔編號】G06F11/14GK103559188SQ201310364684
【公開日】2014年2月5日 申請日期:2013年8月19日 優先權日:2013年8月19日
【發明者】龔福才, 宋懷明, 苗艷超, 劉新春, 邵宗有 申請人:曙光信息產業股份有限公司