TWI677797B - 主備資料庫的管理方法、系統及其設備 - Google Patents
主備資料庫的管理方法、系統及其設備 Download PDFInfo
- Publication number
- TWI677797B TWI677797B TW106130943A TW106130943A TWI677797B TW I677797 B TWI677797 B TW I677797B TW 106130943 A TW106130943 A TW 106130943A TW 106130943 A TW106130943 A TW 106130943A TW I677797 B TWI677797 B TW I677797B
- Authority
- TW
- Taiwan
- Prior art keywords
- database
- lock
- backup
- master
- master database
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/142—Reconfiguring to eliminate the error
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2025—Failover techniques using centralised failover control functionality
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2033—Failover techniques switching over of hardware resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2043—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share a common memory address space
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
- G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/80—Database-specific techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/825—Indexing scheme relating to error detection, to error correction, and to monitoring the problem or solution involving locking
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Hardware Redundancy (AREA)
Abstract
本申請提出一種主備資料庫的管理方法、系統及其設備,其中,方法包括:判斷主資料庫所持有的鎖是否到期,其中,主資料庫和備份資料庫共享鎖;如果判斷主資料庫所持有的鎖已到期,則判斷是否接收到主資料庫的續鎖請求;如果未收到所述主資料庫的續鎖請求,則從備份資料庫中選擇一個作為新的主資料庫,並控制主資料庫切換為備份資料庫。該方法在主資料庫在其持有的鎖到期之前,沒有發送續鎖請求,則判斷主資料庫持有的鎖失效,不能正常為用戶提供服務,從而選擇一個備份資料庫成為新的主資料庫,提高了主備資料庫的切換速率和準確率。
Description
本申請係關於資訊安全技術領域,尤其關於一種主備資料庫的管理方法、系統及其設備。
資料庫是金融、商業、交通等領域乃至整個社會的關鍵基礎設施,資料庫的持續可用是金融、商業等領域可持續向用戶正常進行服務的保障。為了避免單個資料庫發生故障,提升資料庫的可用性,資料庫通常會採用主備配置,當主資料庫故障的時候,切換到備份資料庫繼續進行服務。 相關技術中,主備資料庫可採用自動切換的方式進行切換,即對主資料庫部署監控系統,一旦發現主資料庫異常即發出警報並同時發出命令進行主備資料庫的切換。 然而,上述主備資料庫的切換方式中,可能會因為誤判而導致主資料庫在沒有出現故障的時候發生切換,或者主資料庫發生了故障卻沒有進行切換,從而導致影響了為用戶正常提供服務。
本申請的目的旨在至少在一定程度上解決上述的技術問題之一。 為此,本申請的第一個目的在於提出一種主備資料庫的管理方法,該方法在主資料庫在其持有的鎖到期之前,沒有發送續鎖請求,則判斷主資料庫持有的鎖失效,不能正常為用戶提供服務,從而選擇一個備份資料成為新的主資料庫,提高了主備資料庫的切換速率和準確率。 本申請的第二個目的在於提出一種鎖仲裁伺服器。 本申請的第三個目的在於提出一種主資料庫伺服器。 本申請的第四個目的在於提出一種備份資料庫伺服器。 本申請的第五個目的在於提出一種主備資料庫的管理系統。 為達上述目的,本申請第一方面實施例的主備資料庫的管理方法包括:判斷主資料庫所持有的鎖是否到期,其中,所述主資料庫和備份資料庫共享所述鎖;如果判斷所述主資料庫所持有的鎖已到期,則判斷是否接收到所述主資料庫的續鎖請求;如果未收到所述主資料庫的續鎖請求,則從所述備份資料庫中選擇一個作為新的主資料庫,並控制所述主資料庫切換為備份資料庫。 本申請實施例的主備資料庫的管理方法,判斷主資料庫所持有的鎖是否到期,如果判斷主資料庫持有的鎖已經到期,則判斷是否接收到主資料庫的續鎖請求,如果沒有接收到續鎖請求,則從備份資料庫中選擇一個新的主資料庫,並控制主資料庫切換為備份資料庫。該方法在主資料庫在其持有的鎖到期之前,沒有發送續鎖請求,則判斷主資料庫持有的鎖失效,不能正常為用戶提供服務,從而選擇一個備份資料成為新的主資料庫,提高了主備資料庫的切換速率和準確率。 另外,本申請實施例的主備資料庫的管理方法還具有如下附加的技術特徵: 在本申請的一個實施例中,在判斷所述主資料庫所持有的鎖已到期之後,還包括:向所述備份資料庫發送鎖到期通知;接收所述備份資料庫根據所述鎖到期通知發送的鎖請求,並記錄所述鎖請求的接收時間。 在本申請的一個實施例中,所述從所述備份資料庫中選擇一個作為主資料庫還用於:選擇接收時間最早的備份資料庫作為所述主資料庫。 在本申請的一個實施例中,所述主資料庫的優先級高於所述備份資料庫的優先級。 在本申請的一個實施例中,所述鎖的更新週期為T1,其中,所述主資料庫以週期T2發送查詢所述鎖的狀態的鎖請求,所述備份資料庫以週期T3發送查詢所述鎖的狀態的鎖請求,其中,T2小於T1,T3大於或等於T1。 在本申請的一個實施例中,所述備份資料庫包括熱備資料庫和災備資料庫,其中,所述主資料庫和所述熱備資料庫位於同一資料中心,所述主資料庫和所述災備資料庫位於不同的資料中心。 在本申請的一個實施例中,在原主資料庫恢復之後,還包括:接收所述原主資料庫發送的鎖請求,並在所述鎖到期之後控制所述鎖由所述原主資料庫持有以使所述原主資料庫恢復為主資料庫,且當前主資料庫恢復為備份資料庫。 在本申請的一個實施例中,在從所述備份資料庫中選擇一個作為新的主資料庫之後,還包括:繼續判斷當前主資料庫所持有的鎖是否到期;如果所述當前主資料庫所持有的鎖已到期,則判斷是否收到原主資料庫、所述當前主資料庫和其他備份資料庫的鎖請求;如果接收到所述原主資料庫的鎖請求,則將所述原主資料庫恢復為主資料庫,將所述當前資料庫恢復為備份資料庫;如果未接收到所述原主資料庫的鎖請求,且接收到所述當前主資料庫和其他備份資料庫的鎖請求,則保持所述當前主資料庫作為主資料庫;如果未接收到所述原主資料庫和所述當前主資料庫的鎖請求,且接收到其他備份資料庫的鎖請求,則從所述其他備份資料庫中選擇一個作為主資料庫,並將所述當前主資料庫恢復為備份資料庫。 為達上述目的,本申請第二方面實施例的鎖仲裁伺服器,包括:第一判斷模組,用於判斷主資料庫所持有的鎖是否到期,其中,所述主資料庫和備份資料庫共享所述鎖;第二判斷模組,用於在所述主資料庫所持有的鎖已到期時,判斷是否接收到所述主資料庫的續鎖請求;第一處理模組,用於在未收到所述主資料庫的續鎖請求時,從所述備份資料庫中選擇一個作為新的主資料庫,並控制所述主資料庫切換為備份資料庫。 根據本申請實施例的鎖仲裁伺服器,判斷主資料庫所持有的鎖是否到期,如果判斷主資料庫持有的鎖已經到期,則判斷是否接收到主資料庫的續鎖請求,如果沒有接收到續鎖請求,則從備份資料庫中選擇一個新的主資料庫,並控制主資料庫切換為備份資料庫。該伺服器在主資料庫在其持有的鎖到期之前,沒有發送續鎖請求,則判斷主資料庫持有的鎖失效,不能正常為用戶提供服務,從而選擇一個備份資料成為新的主資料庫,提高了主備資料庫的切換速率和準確率。 另外,本申請實施例的鎖仲裁伺服器,具有如下附加的區別技術特徵: 在本申請的一個實施例中,所述第一處理模組用於:選擇接收時間最早的備份資料庫作為所述主資料庫。 在本申請的一個實施例中,所述主資料庫的優先級高於所述備份資料庫的優先級。 在本申請的一個實施例中,所述鎖的更新週期為T1,所述主資料庫以週期T2發送查詢所述鎖的狀態的鎖請求,所述備份資料庫以週期T3發送查詢所述鎖的狀態的鎖請求,其中,T2小於T1,T3大於或等於T1。 在本申請的一個實施例中,所述備份資料庫包括熱備資料庫和災備資料庫,其中,所述主資料庫和所述熱備資料庫位於同一資料中心,所述主資料庫和所述災備資料庫位於不同的資料中心。 在本申請的一個實施例中,還包括:第一接收模組,用於在原主資料庫恢復之後,接收所述原主資料庫發送的鎖請求;所述第一處理模組,還用於在所述鎖到期之後控制所述鎖由所述原主資料庫持有以使所述原主資料庫恢復為主資料庫,且當前主資料庫恢復為備份資料庫。 在本申請的一個實施例中,所述第一判斷模組,還用於繼續判斷當前主資料庫所持有的鎖是否到期;所述第二判斷模組,還用於在所述當前主資料庫所持有的鎖已到期時,判斷是否收到原主資料庫、所述當前主資料庫和其他備份資料庫的鎖請求;第二處理模組,用於在接收到所述原主資料庫的鎖請求時,將所述原主資料庫恢復為主資料庫,將所述當前資料庫恢復為備份資料庫;第三處理模組,用於在未接收到所述原主資料庫的鎖請求,且接收到所述當前主資料庫和其他備份資料庫的鎖請求時,保持所述當前主資料庫作為主資料庫;第四處理模組,用於在未接收到所述原主資料庫和所述當前主資料庫的鎖請求,且接收到其他備份資料庫的鎖請求時,從所述其他備份資料庫中選擇一個作為主資料庫,並將所述當前主資料庫恢復為備份資料庫。 為達上述目的,本申請第三方面實施例的主資料庫伺服器,包括:第二發送模組,用於在持有的鎖到期時,向鎖仲裁伺服器發送續鎖請求,以便所述鎖仲裁伺服器未收到所述續鎖請求時從備份資料庫中選擇一個作為新的主資料庫;切換模組,用於控制所述主資料庫切換為備份資料庫。 根據本申請實施例的主資料庫伺服器,在持有的鎖到期時,向鎖仲裁伺服器發送續鎖請求,以便鎖仲裁伺服器未接收到續鎖請求時,從備份資料庫中選擇一個作為新的資料庫,同時將主資料庫切換為備份資料庫。該主資料庫伺服器在不能延展主資料庫持有鎖的有效期時,將主資料庫切換為備份資料庫,並選擇一個備份資料成為新的主資料庫,提高了主備資料庫的切換速率和準確率,保證了資料庫正常向用戶提供服務,提升了用戶體驗。 另外,本申請實施例的主資料庫伺服器具有如下附加的技術特徵: 在本申請的一個實施例中,所述主資料庫的優先級高於所述備份資料庫的優先級。 在本申請的一個實施例中,所述鎖的更新週期為T1,其中,所述主資料庫伺服器以週期T2發送查詢所述鎖的狀態的鎖請求,所述備份資料庫以週期T3發送查詢所述鎖的狀態的鎖請求,其中,T2小於T1,T3大於或等於T1。 在本申請的一個實施例中,所述備份資料庫包括熱備資料庫和災備資料庫,其中,所述主資料庫和所述熱備資料庫位於同一資料中心,所述主資料庫和所述災備資料庫位於不同的資料中心。 在本申請的一個實施例中,所述主資料庫伺服器還包括: 第三發送模組,用於在原主資料庫恢復之後,向所述鎖仲裁伺服器發送鎖請求,以便所述鎖仲裁伺服器接收所述原主資料庫發送的鎖請求,並在所述鎖到期之後控制所述鎖由所述原主資料庫持有以使所述原主資料庫恢復為主資料庫,且當前主資料庫恢復為備份資料庫。 為達上述目的,本申請第四方面實施例的備份資料庫伺服器,包括:第四發送模組,用於向鎖仲裁伺服器發送鎖請求;第二接收模組,用於接收所述鎖仲裁伺服器發送的鎖確認訊息;第五處理模組,用於根據所述鎖確認訊息切換為新的主資料庫。 根據本申請實施例的備份資料庫伺服器,向鎖仲裁伺服器發送鎖請求,接收鎖仲裁伺服器發送的鎖確認訊息,根據鎖確認訊息切換為新的主資料庫。該備份資料庫伺服器在主資料庫不能延展主資料庫持有鎖的有效期時,選擇一個備份資料成為新的主資料庫,將主資料庫切換為備份資料庫,提高了主備資料庫的切換速率和準確率,保證了資料庫正常向用戶提供服務,提升了用戶體驗。 本申請實施例的備份資料庫伺服器具有如下附加的技術特徵: 在本申請的一個實施例中,所述備份資料庫伺服器包括:第三接收模組,用於接收所述鎖仲裁伺服器判斷所述主資料庫所持有的鎖已到期之後發送的鎖到期通知,其中,所述第四發送模組根據所述鎖到期通知發送的鎖請求向所述鎖仲裁伺服器發送鎖請求。 在本申請的一個實施例中,所述主資料庫的優先級高於所述備份資料庫的優先級。 在本申請的一個實施例中,所述備份資料庫包括熱備資料庫和災備資料庫,其中,所述主資料庫和所述熱備資料庫位於同一資料中心,所述主資料庫和所述災備資料庫位於不同的資料中心。 在本申請的一個實施例中,所述備份資料庫伺服器還包括:第六處理模組,用於在所述鎖仲裁伺服器接收所述原主資料庫發送的鎖請求,並在所述鎖到期之後控制所述鎖由所述原主資料庫持有以使所述原主資料庫恢復為主資料庫後,控制當前主資料庫恢復為備份資料庫。 為達上述目的,本申請第五方面實施例的主備資料庫的管理系統,包括本申請第二方面實施例所述的鎖仲裁伺服器,本申請第三方面實施例所述的主資料庫伺服器,本申請第四方面實施例所述的備份資料庫伺服器。 本申請附加的方面和優點將在下面的描述中部分給出,部分將從下面的描述中變得明顯,或透過本申請的實踐瞭解到。
下面詳細描述本申請的實施例,所述實施例的示例在附圖中示出,其中自始至終相同或類似的標號表示相同或類似的元件或具有相同或類似功能的元件。下面透過參考附圖描述的實施例是示例性的,旨在用於解釋本申請,而不能理解為對本申請的限制。 下面參考附圖描述本申請一個實施例的主備資料庫的管理方法、系統及其設備。 圖1是根據本申請一個實施例的主備資料庫的管理方法的流程圖,如圖1所示,該主備資料庫的管理方法包括: S110,判斷主資料庫所持有的鎖是否到期,其中,主資料庫和備份資料庫共享鎖。 S120,如果判斷主資料庫所持有的鎖已到期,則判斷是否接收到主資料庫的續鎖請求; 可以理解,為了避免透過監控系統監控並控制主備資料庫的切換方式中,對主備資料庫的誤切換,比如對沒有故障的主資料庫進行切換或者主資料庫發生故障卻不切換,本申請實施例的主備資料庫的管理方法中,引入一個外部的仲裁機制,透過該仲裁機制準確判斷主資料庫是否發生故障,從而準確控制主備資料庫之間的切換。 其中,根據具體應用場景的不同,上述外部的仲裁機制可以有很多種,本申請實施例以該仲裁機制為鎖服務進行詳細描述。 具體地,主資料庫和備份資料庫共享一把鎖,主資料庫和備份資料庫均會競爭鎖的所有權,獲取鎖的資料庫為主資料庫,並且由於鎖具有互斥特徵,所以同一時間只會有一個資料庫可為主資料庫。 主資料庫需要在有效期(通常為幾十秒)到期之前不斷更新鎖以延展其有效期。如果在有效期內,主資料庫發生故障或進行升級維護等,則不能完成對鎖的更新以延展鎖的有效期,從而其他的備份資料庫搶到鎖,升級為主資料庫,而主資料庫降級為備份資料庫。 具體而言,在實際應用中,為了保護主資料庫的不變,避免其在沒有發生故障或進行升級維護等操作時被切換為備份資料庫,主資料庫的優先級高於備份資料庫的優先級,以保證在主資料庫沒有發生故障或進行升級維護等操作的前提下,持有鎖的資料庫是主資料庫。 需要說明的是,上述主備資料庫的部署方式有多種,比如可以是一主一備的部署方式,也可是一主多備的部署方式等。 為了便於描述,在本申請的實施例中,以主備資料庫的部署方式為兩地三中心為例進行描述,即備份資料庫包括熱備資料庫和災備資料庫,其中,主資料庫和熱備資料庫位於同一資料中心,主資料庫和災備資料庫位於不同的資料中心。 進一步地,為了判斷持有鎖的主資料庫是否有故障,判斷其是否在有效期內延展其對鎖持有的有效期。 具體而言,判斷主資料庫持有的鎖是否到期,如果判斷主資料庫所持有的鎖已到期,則判斷是否接收到主資料庫的續鎖請求。 S130,如果未收到主資料庫的續鎖請求,則從備份資料庫中選擇一個作為新的主資料庫,並控制主資料庫切換為備份資料庫。 具體而言,如果未收到主資料庫的續鎖請求,則表明主資料庫網路或者電力等故障,不能完成對鎖的更新,從而為了正常為用戶提供服務,從備份資料庫中選擇一個作為新的主資料庫,並控制主資料庫切換為備份資料庫。 其中,需要說明的是,根據具體應用場景的不同,可採用不同的方式從備份資料庫中選擇一個作為主資料庫。比如,備份資料庫可按一定週期主動查詢主資料庫的鎖到期時,是否發出續鎖請求以延展其持有鎖的有效性,如果沒有,則備份資料庫發出鎖請求,以便能夠迅速獲取鎖並切換成主資料庫。 為了更加清楚的說明本申請實施例的主備資料庫的管理方法,下面結合圖2(a)-圖2(b)以資料庫部署方式為兩地三中心部署方式為例進行說明,即如圖2(a)所示,在同城的主機房和熱備機房同時部署兩個資料庫(主資料庫和熱備資料庫),在異地的災備機房部署一個獨立的資料庫(災備資料庫)。 在本示例中,外部仲裁機制服務GOS本身可跨地部署,可以包容機房以及佈局地區完全失效,或是網路的故障,可始終提供不間斷的鎖服務。 圖2(b)是根據本申請一個實施例的主備資料庫切換示意圖。 如圖2(b)所示,如果主機房整體失效,比如主機房的機房損壞或者是網路故障,則其無法發出續鎖請求,從而不能延展其持有鎖的有效期,其持有的鎖最終會失效,這個過程通常會持續幾十秒,在此期間,主資料庫無法正常為用戶提供服務。 在鎖的有效期過後,通常熱備機房會獲得新鎖,從而熱備資料庫會成為新的主資料庫,原來的主資料庫自動降級為備份資料庫,進而熱備資料庫作為新的主資料庫為用戶提供服務,災備機房從新的主資料庫中獲取最新的資料,並同步到本地。 綜上所述,本申請實施例的主備資料庫的管理方法,判斷主資料庫所持有的鎖是否到期,如果判斷主資料庫持有的鎖已經到期,則判斷是否接收到主資料庫的續鎖請求,如果沒有接收到續鎖請求,則從備份資料庫中選擇一個新的主資料庫,並控制主資料庫切換為備份資料庫。該方法在主資料庫在其持有的鎖到期之前,沒有發送續鎖請求,則判斷主資料庫持有的鎖失效,不能正常為用戶提供服務,從而選擇一個備份資料成為新的主資料庫,提高了主備資料庫的切換速率和準確率。 基於上述實施例,主備資料庫管理方法中,主備資料庫的切換方式可以分為主動切換和被動切換兩種方式,具體說明如下: 作為一種示例,為了使得主資料庫能夠及時對鎖進行更新,以及在主資料庫發生故障時,其他備份資料庫能夠迅速獲取鎖,主資料庫可在鎖的更新週期內,以相對較短的週期發送查詢鎖的狀態請求,從而在鎖將要失效時及時對其更新,維持當前的主資料庫的不變性。 同時,備份資料庫以相對較長的週期主動發送查詢鎖的狀態的鎖請求,從而在主資料庫的鎖失效時,能夠迅速獲取鎖,進而主動切換成為新的主資料庫,不影響為用戶提供服務。 舉例而言,如果鎖的更新週期為T1,主資料庫以週期T2發送查詢鎖的狀態的鎖請求,備份資料庫以週期T3發送查詢鎖的狀態的鎖請求,其中,T2小於T1,T3大於或等於T1。 作為另一種示例,如果備份資料庫不是始終主動以一定的週期,發送查詢鎖的狀態的鎖請求,則在主資料庫持有的鎖失效時,主動向其他備份資料庫發送鎖到期通知,以便備份資料庫根據鎖到期通知發送鎖請求,獲取鎖成為新的主資料庫。 具體而言,圖3是根據本申請另一個實施例的主備資料庫的管理方法的流程圖,如圖3所示, S310,判斷主資料庫所持有的鎖是否到期,其中,主資料庫和備份資料庫共享鎖。 S320,如果判斷主資料庫所持有的鎖已到期,向備份資料庫發送鎖到期通知。 S330,接收備份資料庫根據鎖到期通知發送的鎖請求,並記錄鎖請求的接收時間。 S340,判斷是否接收到主資料庫的續鎖請求。 S350,如果未收到主資料庫的續鎖請求,選擇接收時間最早的備份資料庫作為主資料庫。 可以理解,主資料庫和備份資料庫之間的資料是進行準即時同步的,同步的速度取決於資料庫的備份速度,通常同城機房的延遲在幾毫秒,而異地機房的延時在數百毫秒。 並且如果主資料庫的切換時主動發起的,比如是進行版本升級或者是下線維護,可以做到在主資料庫放棄主資料庫的身份之前,停止寫入資料,熱備機房獲取鎖,熱備資料庫能夠同步更新完成所有的資料,因此在一般情況下,熱備資料庫的資料較完整,因此有限將熱備資料庫作為下一個主資料庫。 具體而言,根據接收到的鎖請求的時間,判斷出距離主資料庫較近的備份資料庫。即由於不同的備份資料庫可能與當前主資料庫的距離不同,比如熱備資料庫一般距離主資料庫較近,而災備資料庫一般距離主資料較遠,因此其接收到鎖請求的時間不同,熱備資料庫接收到的請求的時間較早。 進一步地,如果未接收到主資料庫的續鎖請求,表明當前的資料庫出現故障或在進行升級維護等,因此為了儘快正常為用戶提供服務,選擇接收時間最早的備份資料庫作為主資料庫。 另外,應當理解的是,當處於同一個資料中心的主資料庫和熱備資料庫出現災難性的故障的時候,比如發生地震等,本申請實施例的主備資料庫的管理方法仍可實現。 如圖2(c)所示,當主資料庫和熱備資料庫所在機房都發生故障,則主資料庫的鎖就會失效,而熱備資料庫也無法獲得鎖,因此,災備資料庫將獲得鎖成為新的主資料庫,繼續為用戶提供服務,整個過程無需人工參與。 綜上所述,本申請實施例的主備資料庫的管理方法,在主資料庫的鎖到期失效時,備份資料庫迅速獲取鎖成為新的主資料庫,保證在較短的時間內,繼續為用戶正常的提供服務,提升了用戶體驗。 在實際應用中,出現故障的原主資料庫經過維修、升級等相關操作後,可為用戶繼續提供服務,因此本申請實施例的主備資料庫的管理方法還包括,在原主資料庫恢復後,接收原主資料庫的鎖請求,以將其切換為主資料庫。 具體而言,在本示例中,在從備份資料庫中選擇一個作為新的主資料庫之後,始終檢測當前主資料庫的鎖的有效性和原主資料庫的鎖請求,在當前主資料庫鎖失效時,再次從其他備份資料庫中選擇一個新的主資料庫,或者在接收到原主資料庫的鎖請求後,由於原主資料庫的優先級較高,將原主資料庫切換為主資料庫,將當前主資料庫降級為備份資料庫。 圖4是根據本申請又一個實施例的主備資料庫的管理方法的流程圖,如圖4所示,該主備資料庫的管理方法包括: S410,繼續判斷當前主資料庫所持有的鎖是否到期。 S420,如果當前主資料庫所持有的鎖已到期,則判斷是否收到原主資料庫、當前主資料庫和其他備份資料庫的鎖請求。 S430,如果接收到原主資料庫的鎖請求,則將原主資料庫恢復為主資料庫,將當前資料庫恢復為備份資料庫。 具體而言,原主資料庫在恢復正常後,發送鎖請求,由於原主資料庫的優先級較高,在接收到該鎖請求後,則將原主資料庫恢復為主資料庫,將當前主資料庫恢復為備份資料庫。 S440,如果未接收到原主資料庫的鎖請求,且接收到當前主資料庫和其他備份資料庫的鎖請求,則保持當前主資料庫作為主資料庫。 具體而言,在未接收到原主資料庫的鎖請求,且當前主資料庫正常更新鎖,則繼續保持當前主資料庫作為主資料庫。 S450,如果未接收到原主資料庫和當前主資料庫的鎖請求,且接收到其他備份資料庫的鎖請求,則從其他備份資料庫中選擇一個作為主資料庫,並將當前主資料庫恢復為備份資料庫。 具體而言,如果未接收到原主資料庫和當前主資料庫的鎖請求,則表明原主資料庫未回復正常,且當前的主資料庫也出現故障或需要進行升級操作等,因而為了為用戶正常提供服務,需從發送鎖請求的其他備份資料庫中選擇一個作為主資料庫,並將當前主資料庫恢復為備份資料庫。 綜上所述,本申請實施例的主備資料庫的管理方法,在從備份資料庫中選擇一個作為新的主資料庫後,繼續判斷當前主資料庫是否接收到原主資料庫的鎖請求,以及當前主資料庫是否進行鎖的更新,當接收到原主資料庫的鎖請求,則將原主資料庫恢復為當前主資料庫,將當前主資料庫恢復為備份資料庫,如果沒有接收到原主資料庫的鎖請求,則判斷前主資料庫是否有效進行鎖的更新,如果沒有,則從其他備份資料庫中選擇一個作為主資料庫,並將當前主資料庫恢復為備份資料庫。該方法保證了在原主資料庫恢復後,將其恢復為主資料庫,能夠更好的為用戶提供服務,提高了本申請主備資料庫的管理方法的實用性。 為了實現上述實施例,本申請還提出了一種鎖仲裁伺服器。圖5是根據本申請一個實施例的鎖仲裁伺服器的結構示意圖。 如圖5所示,該鎖仲裁伺服器包括: 第一判斷模組510,用於判斷主資料庫所持有的鎖是否到期,其中,主資料庫和備份資料庫共享鎖。 第二判斷模組520,用於在主資料庫所持有的鎖已到期時,判斷是否接收到主資料庫的續鎖請求。 第一處理模組530,用於在未收到主資料庫的續鎖請求時,從備份資料庫中選擇一個作為新的主資料庫,並控制主資料庫切換為備份資料庫。 具體而言,在實際應用中,為了保護主資料庫的不變,避免其在沒有發生故障或進行升級維護等操作時被切換為備份資料庫,主資料庫的優先級高於備份資料庫的優先級,以保證在主資料庫沒有發生故障或進行升級維護等操作的前提下,持有鎖的資料庫是主資料庫。 需要說明的是,上述主備資料庫的部署方式有多種,比如可以是一主一備的部署方式,也可是一主多備的部署方式等。 為了便於描述,在本申請的實施例中,以主備資料庫的部署方式為兩地三中心為例進行描述,即備份資料庫包括熱備資料庫和災備資料庫,其中,主資料庫和熱備資料庫位於同一資料中心,主資料庫和災備資料庫位於不同的資料中心。 進一步地,為了判斷持有鎖的主資料庫是否有故障,判斷其是否在有效期內延展其對鎖持有的有效期。 具體而言,第一判斷模組510判斷主資料庫持有的鎖是否到期,如果判斷主資料庫所持有的鎖已到期,第二判斷模組520則判斷是否接收到主資料庫的續鎖請求。 進而,如果未收到主資料庫的續鎖請求,則表明主資料庫網路或者電力等故障,不能完成對鎖的更新,從而為了正常為用戶提供服務,第一處理模組530從備份資料庫中選擇一個作為新的主資料庫,並控制主資料庫切換為備份資料庫。 其中,需要說明的是,根據具體應用場景的不同,第一處理模組530可採用不同的方式從備份資料庫中選擇一個作為主資料庫。比如,備份資料庫可按一定週期主動查詢主資料庫的鎖到期時,是否發出續鎖請求以延展其持有鎖的有效性,如果沒有,則備份資料庫發出鎖請求,以便能夠迅速獲取鎖並切換成主資料庫。 綜上所述,本申請實施例的鎖仲裁伺服器,判斷主資料庫所持有的鎖是否到期,如果判斷主資料庫持有的鎖已經到期,則判斷是否接收到主資料庫的續鎖請求,如果沒有接收到續鎖請求,則從備份資料庫中選擇一個新的主資料庫,並控制主資料庫切換為備份資料庫。該鎖仲裁伺服器在主資料庫在其持有的鎖到期之前,沒有發送續鎖請求,則判斷主資料庫持有的鎖失效,不能正常為用戶提供服務,從而選擇一個備份資料成為新的主資料庫,提高了主備資料庫的切換速率和準確率。 基於上述實施例,主備資料庫管理方法中,主備資料庫的切換方式可以分為主動切換和被動切換兩種方式,具體說明如下: 作為一種示例,為了使得主資料庫能夠及時對鎖進行更新,以及在主資料庫發生故障時,其他備份資料庫能夠迅速獲取鎖,主資料庫可在鎖的更新週期內,以相對較短的週期發送查詢鎖的狀態請求,從而在鎖將要失效時及時對其更新,維持當前的主資料庫的不變性。 同時,備份資料庫以相對較長的週期主動發送查詢鎖的狀態的鎖請求,從而在主資料庫的鎖失效時,能夠迅速獲取鎖,進而主動切換成為新的主資料庫,不影響為用戶提供服務。 舉例而言,如果鎖的更新週期為T1,主資料庫以週期T2發送查詢鎖的狀態的鎖請求,備份資料庫以週期T3發送查詢鎖的狀態的鎖請求,其中,T2小於T1,T3大於或等於T1。 作為另一種示例,如果備份資料庫不是始終主動以一定的週期,發送查詢鎖的狀態的鎖請求,則在主資料庫持有的鎖失效時,主動向其他備份資料庫發送鎖到期通知,以便備份資料庫根據鎖到期通知發送鎖請求,獲取鎖成為新的主資料庫。 具體而言,圖6是根據本申請一個具體實施例的鎖仲裁伺服器的結構示意圖,如圖6所示,在如圖5所示的基礎上,該鎖仲裁伺服器還包括:第一發送模組540和記錄模組550。 具體而言,第一發送模組在第一判斷模組510判斷主資料庫所有的鎖已到期後,向備份資料庫發送鎖到期通知,進而記錄模組550接收備份資料庫根據鎖到期通知發送的鎖請求,並記錄鎖請求的接收時間。 進而,如果未接收到主資料庫的續鎖請求,表明當前的資料庫出現故障或在進行升級維護等,因此為了儘快正常為用戶提供服務,第一處理模組530選擇接收時間最早的備份資料庫作為主資料庫。 綜上所述,本申請實施例的鎖仲裁伺服器,在主資料庫的鎖到期失效時,備份資料庫迅速獲取鎖成為新的主資料庫,保證在較短的時間內,繼續為用戶正常的提供服務,提升了用戶體驗。 在實際應用中,出現故障的原主資料庫經過維修、升級等相關操作後,可為用戶繼續提供服務,因此本申請實施例的鎖仲裁伺服器還用於,在原主資料庫恢復後,接收原主資料庫的鎖請求,以將其切換為主資料庫。 圖7是根據本申請另一個實施例的鎖仲裁伺服器的結構示意圖。如圖7所示,在如圖5所示的基礎上,該鎖仲裁伺服器還包括:第一接收模組560。具體而言,在本示例中,第一處理模組530在從備份資料庫中選擇一個作為新的主資料庫之後,第一接收模組560始終接收原主資料庫的鎖請求,在第一接收模組560接收到原主資料庫的鎖請求後,由於原主資料庫的優先級較高,第一處理模組530將原主資料庫切換為主資料庫,將當前主資料庫降級為備份資料庫。 作為一種實現方式,圖8是根據本申請又一個實施例的鎖仲裁伺服器的結構示意圖。如圖8所示,在如圖5所示的基礎上,該鎖仲裁伺服器還包括:第二處理模組570,第三處理模組580和第四處理模組590。 具體而言,在從備份資料庫中選擇一個作為新的主資料庫之後,第一判斷模組510繼續判斷當前主資料庫所持有的鎖是否到期,第二判斷模組520在當前主資料庫所持有的鎖已到期,則判斷是否收到原主資料庫、當前主資料庫和其他備份資料庫的鎖請求。 如果接收到原主資料庫的鎖請求,第二處理模組570則將原主資料庫恢復為主資料庫,將當前資料庫恢復為備份資料庫。 具體而言,原主資料庫在恢復正常後,發送鎖請求,由於原主資料庫的優先級較高,在接收到該鎖請求後,則將原主資料庫恢復為主資料庫,第二處理模組570將當前主資料庫恢復為備份資料庫。 如果未接收到原主資料庫的鎖請求,且接收到當前主資料庫和其他備份資料庫的鎖請求,第三處理模組580則保持當前主資料庫作為主資料庫。 具體而言,在未接收到原主資料庫的鎖請求,且當前主資料庫正常更新鎖,第三處理模組580則繼續保持當前主資料庫作為主資料庫。 如果未接收到原主資料庫和當前主資料庫的鎖請求,且接收到其他備份資料庫的鎖請求,第四處理模組590則從其他備份資料庫中選擇一個作為主資料庫,並將當前主資料庫恢復為備份資料庫。 具體而言,如果未接收到原主資料庫和當前主資料庫的鎖請求,則表明原主資料庫未回復正常,且當前的主資料庫也出現故障或需要進行升級操作等,因而為了為用戶正常提供服務,第四處理模組590需從發送鎖請求的其他備份資料庫中選擇一個作為主資料庫,並將當前主資料庫恢復為備份資料庫。 需要說明的是,本申請鎖仲裁伺服器中未披露的細節,參考上述結合附圖1-4描述的主備資料庫的管理方法的實施例,在此不再贅述。 綜上所述,本申請實施例的鎖仲裁伺服器,在從備份資料庫中選擇一個作為新的主資料庫後,繼續判斷當前主資料庫是否接收到原主資料庫的鎖請求,以及當前主資料庫是否進行鎖的更新,當接收到原主資料庫的鎖請求,則將原主資料庫恢復為當前主資料庫,將當前主資料庫恢復為備份資料庫,如果沒有接收到原主資料庫的鎖請求,則判斷前主資料庫是否有效進行鎖的更新,如果沒有,則從其他備份資料庫中選擇一個作為主資料庫,並將當前主資料庫恢復為備份資料庫。該鎖仲裁伺服器保證了在原主資料庫恢復後,將其恢復為主資料庫,能夠更好的為用戶提供服務,提高了本申請主備資料庫的管理方法的實用性。 為了實現上述實施例,本申請還提出了一種主資料庫伺服器。 圖9是根據本申請一個實施例的主資料庫伺服器的結構示意圖,如圖9所示,該主資料庫伺服器包括: 第二發送模組910,用於在持有的鎖到期時,向鎖仲裁伺服器發送續鎖請求,以便鎖仲裁伺服器未收到續鎖請求時從備份資料庫中選擇一個作為新的主資料庫。 切換模組920,用於控制主資料庫切換為備份資料庫。 具體而言,在實際應用中,為了保護主資料庫的不變,避免其在沒有發生故障或進行升級維護等操作時被切換為備份資料庫,主資料庫的優先級高於備份資料庫的優先級,以保證在主資料庫沒有發生故障或進行升級維護等操作的前提下,持有鎖的資料庫是主資料庫。 需要說明的是,上述主備資料庫的部署方式有多種,比如可以是一主一備的部署方式,也可是一主多備的部署方式等。 為了便於描述,在本申請的實施例中,以主備資料庫的部署方式為兩地三中心為例進行描述,即備份資料庫包括熱備資料庫和災備資料庫,其中,主資料庫和熱備資料庫位於同一資料中心,主資料庫和災備資料庫位於不同的資料中心。 具體而言,第二發送模組910在持有的鎖到期時,向鎖仲裁伺服器發送鎖請求,如果鎖仲裁伺服器未收到鎖請求,則表示當前主資料庫在進行升級更新或者故障等從而不能正常為用戶提供伺服器,從而鎖仲裁伺服器從備份資料庫中選擇一個作為新的主資料庫,以為用戶儘快提供正常服務,同時切換模組920控制主資料庫切換為備份資料庫。 其中,應當理解的是,為了使得主資料庫能夠及時對鎖進行更新,以及在主資料庫發生故障時,其他備份資料庫能夠迅速獲取鎖,主資料庫可在鎖的更新週期內,以相對較短的週期發送查詢鎖的狀態請求,從而在鎖將要失效時及時對其更新,維持當前的主資料庫的不變性。 同時,備份資料庫以相對較長的週期主動發送查詢鎖的狀態的鎖請求,從而在主資料庫的鎖失效時,能夠迅速獲取鎖,進而主動切換成為新的主資料庫,不影響為用戶提供服務。 舉例而言,如果鎖的更新週期為T1,主資料庫以週期T2發送查詢鎖的狀態的鎖請求,備份資料庫以週期T3發送查詢鎖的狀態的鎖請求,其中,T2小於T1,T3大於或等於T1。 綜上所述,根據本申請實施例的主資料庫伺服器,在持有的鎖到期時,向鎖仲裁伺服器發送續鎖請求,以便鎖仲裁伺服器未接收到續鎖請求時,從備份資料庫中選擇一個作為新的資料庫,同時將主資料庫切換為備份資料庫。該主資料庫伺服器在不能延展主資料庫持有鎖的有效期時,將主資料庫切換為備份資料庫,並選擇一個備份資料成為新的主資料庫,提高了主備資料庫的切換速率和準確率,保證了資料庫正常向用戶提供服務,提升了用戶體驗。 在實際應用中,出現故障的原主資料庫經過維修、升級等相關操作後,可為用戶繼續提供服務,因此本申請實施例的主備資料庫伺服器還用於,在原主資料庫恢復後,接收原主資料庫的鎖請求,以將其切換為主資料庫。 圖10是根據本申請一個具體實施例的主資料庫伺服器的結構示意圖,如圖10所示,在如圖9所示的基礎上,該主資料庫伺服器還包括:第三發送模組930。 具體而言,原主資料庫在恢復正常後,通過第三發送模組930發送鎖請求,由於原主資料庫的優先級較高,在接收到該鎖請求後,鎖仲裁伺服器接收原主資料庫發送的鎖請求,並在鎖到期之後控制鎖由原主資料庫持有以使原主資料庫恢復為主資料庫,且當前主資料庫恢復為備份資料庫。 其中,需要強調的是,本申請主資料庫伺服器中未披露的細節,參照上述結合圖1-圖4對主備資料庫的管理方法的描述,在此不再贅述。 綜上所述,本申請實施例的主備資料庫伺服器,保證了在原主資料庫恢復後,將其恢復為主資料庫,能夠更好的為用戶提供服務,提升了用戶體驗。 為了實現上述實施例,本申請還提出了一種備份資料庫伺服器。圖11是根據本申請一個實施例的備份資料庫的結構示意圖,如圖11所示,該備份資料庫包括: 第四發送模組1010,用於向鎖仲裁伺服器發送鎖請求。 第二接收模組1020,用於接收鎖仲裁伺服器發送的鎖確認訊息。 第五處理模組1030,用於根據鎖確認訊息切換為新的主資料庫。 可以理解,在實際應用中,為了保護主資料庫的不變,避免其在沒有發生故障或進行升級維護等操作時被切換為備份資料庫,主資料庫的優先級高於備份資料庫的優先級,以保證在主資料庫沒有發生故障或進行升級維護等操作的前提下,持有鎖的資料庫是主資料庫。然而當主資料庫不能有效延展其持有鎖的有效期時,鎖仲裁伺服器需要從備份資料庫中選擇一個作為主資料庫繼續為用戶提供服務。 具體地,第四發送模組1010向鎖仲裁伺服器發送鎖請求,以便於在主資料庫不能有效更新鎖時,迅速搶到鎖,第二接收模組1020接收鎖仲裁伺服器發送的鎖確認訊息,從而第五處理模組1030根據鎖的確認訊息切換為主資料庫。 需要說明的是,上述主備資料庫的部署方式有多種,比如可以是一主一備的部署方式,也可是一主多備的部署方式等。 為了便於描述,在本申請的實施例中,以主備資料庫的部署方式為兩地三中心為例進行描述,即備份資料庫包括熱備資料庫和災備資料庫,其中,主資料庫和熱備資料庫位於同一資料中心,主資料庫和災備資料庫位於不同的資料中心。 綜上所述,本申請實施例的備份資料庫伺服器,向鎖仲裁伺服器發送鎖請求,在判斷主資料庫持有的鎖失效,不能正常為用戶提供服務時,切換為新的主資料庫,提高了主備資料庫的切換速率和準確率,保證為用戶正常提供服務,提升了用戶體驗。 基於以上實施例,如果備份資料庫伺服器不是始終主動以一定的週期,發送查詢鎖的狀態的鎖請求,則在主資料庫持有的鎖失效時,主動向其他備份資料庫發送鎖到期通知,以便備份資料庫伺服器根據鎖到期通知發送鎖請求,獲取鎖成為新的主資料庫。 具體而言,圖12是根據本申請一個具體實施例的備份資料庫伺服器的結構示意圖,如圖12所示,在如圖11所示的基礎上,該備份資料庫伺服器包括:第三接收模組1040。 具體地,第三接收模組1040接收鎖仲裁伺服器判斷主資料庫所持有的鎖已到期之後發送的鎖到期通知,其中,第四發送模組1010根據鎖到期通知發送的鎖請求向鎖仲裁伺服器發送鎖請求。 進而,如果在鎖到期時,所仲裁伺服器未接收到主資料庫的續鎖請求,表明當前的資料庫出現故障或在進行升級維護等,因此為了儘快正常為用戶提供服務,鎖仲裁伺服器選擇接收時間最早的備份資料庫作為主資料庫。 綜上所述,本申請實施例的備份資料庫伺服器,在主資料庫的鎖到期失效時,備份資料庫迅速獲取鎖成為新的主資料庫,保證在較短的時間內,繼續為用戶正常的提供服務,提升了用戶體驗。 在實際應用中,出現故障的原主資料庫經過維修、升級等相關操作後,可為用戶繼續提供服務,因此本申請實施例的備份資料庫伺服器還用於,在原主資料庫恢復後,切換為備份資料庫。 圖13是根據本申請另一個實施例的備份資料庫伺服器的結構示意圖,如圖13所示,在如圖11所示的基礎上,該備份資料庫伺服器包括:第六處理模組1050。 具體而言,原主資料庫在恢復正常後,發送鎖請求,由於原主資料庫的優先級較高,鎖仲裁伺服器在接收到該鎖請求後,則將原主資料庫恢復為主資料庫,第六處理模組1050則將當前主資料庫恢復為備份資料庫。 應當理解的是,本申請實施例的備份資料庫伺服器中未披露的細節,參照以上結合圖1-圖4描述的主備資料庫的管理方法的實施例,在此不再贅述。 綜上所述,本申請實施例的備份資料庫伺服器,在原主資料庫恢復後,將其恢復為備份資料庫,並且仲裁伺服器將原主資料庫恢復為主資料庫,能夠更好的為用戶提供服務,提升了用戶體驗。 為了實現上述實施例,本申請還提出了一種主備資料庫的管理系統,圖14是根據本申請一個實施例的主備資料庫的管理系統的結構示意圖,如圖14所示,該主備資料庫的管理系統包括:鎖仲裁伺服器1000,主資料庫伺服器2000和備份資料庫伺服器3000。 需要說明的是,本申請中對鎖仲裁伺服器1000,主資料庫伺服器2000和備份資料庫伺服器3000的描述,參照上述對鎖仲裁伺服器,主資料庫伺服器和備份資料庫伺服器的描述,在此不再贅述。 綜上所述,本申請實施例的主備資料庫的管理系統,判斷主資料庫所持有的鎖是否到期,如果判斷主資料庫持有的鎖已經到期,則判斷是否接收到主資料庫的續鎖請求,如果沒有接收到續鎖請求,則從備份資料庫中選擇一個新的主資料庫,並控制主資料庫切換為備份資料庫。該系統在主資料庫在其持有的鎖到期之前,沒有發送續鎖請求,則判斷主資料庫持有的鎖失效,不能正常為用戶提供服務,從而選擇一個備份資料成為新的主資料庫,提高了主備資料庫的切換速率和準確率。 此外,術語“第一”、“第二”僅用於描述目的,而不能理解為指示或暗示相對重要性或者隱含指明所指示的技術特徵的數量。由此,限定有“第一”、“第二”的特徵可以明示或者隱含地包括至少一個該特徵。在本申請的描述中,“多個”的含義是至少兩個,例如兩個,三個等,除非另有明確具體的限定。 在本說明書的描述中,參考術語“一個實施例”、“一些實施例”、“示例”、“具體示例”、或“一些示例”等的描述意指結合該實施例或示例描述的具體特徵、結構、材料或者特點包含於本申請的至少一個實施例或示例中。在本說明書中,對上述術語的示意性表述不必須針對的是相同的實施例或示例。而且,描述的具體特徵、結構、材料或者特點可以在任一個或多個實施例或示例中以合適的方式結合。此外,在不相互矛盾的情況下,本領域的技術人員可以將本說明書中描述的不同實施例或示例以及不同實施例或示例的特徵進行結合和組合。 儘管上面已經示出和描述了本申請的實施例,可以理解的是,上述實施例是示例性的,不能理解為對本申請的限制,本領域的普通技術人員在本申請的範圍內可以對上述實施例進行變化、修改、替換和變型。
510‧‧‧第一判斷模組
520‧‧‧第二判斷模組
530‧‧‧第一處理模組
540‧‧‧第一發送模組
550‧‧‧記錄模組
560‧‧‧第一接收模組
570‧‧‧第二處理模組
580‧‧‧第三處理模組
590‧‧‧第四處理模組
910‧‧‧第二發送模組
920‧‧‧切換模組
930‧‧‧第三發送模組
1010‧‧‧第四發送模組
1020‧‧‧第二接收模組
1030‧‧‧第五處理模組
1040‧‧‧第三接收模組
1050‧‧‧第六處理模組
1000‧‧‧鎖仲裁伺服器
2000‧‧‧主資料庫伺服器
3000‧‧‧備份資料庫伺服器
本申請的上述和/或附加的方面和優點從結合下面附圖對實施例的描述中將變得明顯和容易理解,其中: 圖1是根據本申請一個實施例的主備資料庫的管理方法的流程圖; 圖2(a)-圖2(c)是根據本申請一個具體實施例的主備資料庫部署圖; 圖3是根據本申請另一個實施例的主備資料庫的管理方法的流程圖; 圖4是根據本申請又一個實施例的主備資料庫的管理方法的流程圖; 圖5是根據本申請一個實施例的鎖仲裁伺服器的結構示意圖; 圖6是根據本申請一個具體實施例的鎖仲裁伺服器的結構示意圖; 圖7是根據本申請另一個實施例的鎖仲裁伺服器的結構示意圖; 圖8是根據本申請又一個實施例的鎖仲裁伺服器的結構示意圖; 圖9是根據本申請一個實施例的主資料庫伺服器的結構示意圖; 圖10是根據本申請一個具體實施例的主資料庫伺服器的結構示意圖; 圖11是根據本申請一個實施例的備份資料庫的結構示意圖; 圖12是根據本申請一個具體實施例的備份資料庫伺服器的結構示意圖; 圖13是根據本申請另一個實施例的備份資料庫伺服器的結構示意圖;以及 圖14是根據本申請一個實施例的主備資料庫的管理系統的結構示意圖。
Claims (22)
- 一種主備資料庫的管理方法,其特徵在於,包括以下步驟:判斷主資料庫所持有的鎖是否到期,其中,該主資料庫和備份資料庫共享該鎖;如果判斷該主資料庫所持有的鎖已到期,則判斷是否接收到該主資料庫的續鎖請求;如果未收到該主資料庫的續鎖請求,則從該備份資料庫中選擇一個作為新的主資料庫,並控制該主資料庫切換為備份資料庫。
- 如請求項1所述的主備資料庫的管理方法,其中,在判斷該主資料庫所持有的鎖已到期之後,還包括:向該備份資料庫發送鎖到期通知;接收該備份資料庫根據該鎖到期通知發送的鎖請求,並記錄該鎖請求的接收時間。
- 如請求項2所述的主備資料庫的管理方法,其中,所述從該備份資料庫中選擇一個作為主資料庫具體包括:選擇接收時間最早的備份資料庫作為該主資料庫。
- 如請求項1所述的主備資料庫的管理方法,其中,該主資料庫的優先級高於該備份資料庫的優先級。
- 如請求項1所述的主備資料庫的管理方法,其中,該鎖的更新週期為T1,該主資料庫以週期T2發送查詢該鎖的狀態的鎖請求,該備份資料庫以週期T3發送查詢該鎖的狀態的鎖請求,其中,T2小於T1,T3大於或等於T1。
- 如請求項1所述的主備資料庫的管理方法,其中,該備份資料庫包括熱備資料庫和災備資料庫,其中,該主資料庫和該熱備資料庫位於同一資料中心,該主資料庫和該災備資料庫位於不同的資料中心。
- 如請求項4或5所述的主備資料庫的管理方法,其中,在原主資料庫恢復之後,還包括:接收該原主資料庫發送的鎖請求,並在該鎖到期之後控制該鎖由該原主資料庫持有以使該原主資料庫恢復為主資料庫,且當前主資料庫恢復為備份資料庫。
- 如請求項1所述的主備資料庫的管理方法,其中,在從該備份資料庫中選擇一個作為新的主資料庫之後,還包括:繼續判斷當前主資料庫所持有的鎖是否到期;如果該當前主資料庫所持有的鎖已到期,則判斷是否收到原主資料庫、該當前主資料庫和其他備份資料庫的鎖請求;如果接收到該原主資料庫的鎖請求,則將該原主資料庫恢復為主資料庫,將該當前資料庫恢復為備份資料庫;如果未接收到該原主資料庫的鎖請求,且接收到該當前主資料庫和其他備份資料庫的鎖請求,則保持該當前主資料庫作為主資料庫;如果未接收到該原主資料庫和該當前主資料庫的鎖請求,且接收到其他備份資料庫的鎖請求,則從該其他備份資料庫中選擇一個作為主資料庫,並將該當前主資料庫恢復為備份資料庫。
- 一種鎖仲裁伺服器,其特徵在於,包括:第一判斷模組,用於判斷主資料庫所持有的鎖是否到期,其中,該主資料庫和備份資料庫共享該鎖;第二判斷模組,用於在該主資料庫所持有的鎖已到期時,判斷是否接收到該主資料庫的續鎖請求;第一處理模組,用於在未收到該主資料庫的續鎖請求時,從該備份資料庫中選擇一個作為新的主資料庫,並控制該主資料庫切換為備份資料庫。
- 如請求項9所述的鎖仲裁伺服器,其中,還包括:第一發送模組,用於在該第一判斷模組判斷該主資料庫所有的鎖已到期後,向該備份資料庫發送鎖到期通知;記錄模組,用於接收該備份資料庫根據該鎖到期通知發送的鎖請求,並記錄該鎖請求的接收時間。
- 如請求項10所述的鎖仲裁伺服器,其中,該第一處理模組,還用於:選擇接收時間最早的備份資料庫作為該主資料庫。
- 如請求項9所述的鎖仲裁伺服器,其中,該主資料庫的優先級高於該備份資料庫的優先級。
- 如請求項9所述的鎖仲裁伺服器,其中,該鎖的更新週期為T1,其中,該主資料庫以週期T2發送查詢該鎖的狀態的鎖請求,該備份資料庫以週期T3發送查詢該鎖的狀態的鎖請求,其中,T2小於T1,T3大於或等於T1。
- 如請求項9所述的鎖仲裁伺服器,其中,該備份資料庫包括熱備資料庫和災備資料庫,其中,該主資料庫和該熱備資料庫位於同一資料中心,該主資料庫和該災備資料庫位於不同的資料中心。
- 如請求項12或13所述的鎖仲裁伺服器,其中,還包括:第一接收模組,用於在原主資料庫恢復之後,接收該原主資料庫發送的鎖請求;該第一處理模組,還用於在該鎖到期之後控制該鎖由該原主資料庫持有以使該原主資料庫恢復為主資料庫,且當前主資料庫恢復為備份資料庫。
- 如請求項9所述的鎖仲裁伺服器,其中:該第一判斷模組,還用於繼續判斷當前主資料庫所持有的鎖是否到期;該第二判斷模組,還用於在該當前主資料庫所持有的鎖已到期時,判斷是否收到原主資料庫、該當前主資料庫和其他備份資料庫的鎖請求;第二處理模組,用於在接收到該原主資料庫的鎖請求時,將該原主資料庫恢復為主資料庫,將該當前資料庫恢復為備份資料庫;第三處理模組,用於在未接收到該原主資料庫的鎖請求,且接收到該當前主資料庫和其他備份資料庫的鎖請求時,保持該當前主資料庫作為主資料庫;第四處理模組,用於在未接收到該原主資料庫和該當前主資料庫的鎖請求,且接收到其他備份資料庫的鎖請求時,從該其他備份資料庫中選擇一個作為主資料庫,並將該當前主資料庫恢復為備份資料庫。
- 一種主資料庫伺服器,其特徵在於,包括:第二發送模組,用於在持有的鎖到期時,向鎖仲裁伺服器發送續鎖請求,以便該鎖仲裁伺服器未收到該續鎖請求時從備份資料庫中選擇一個作為新的主資料庫;切換模組,用於控制該主資料庫切換為備份資料庫。
- 如請求項17所述的主資料庫伺服器,其中,該主資料庫的優先級高於該備份資料庫的優先級。
- 如請求項17所述的主資料庫伺服器,其中,該鎖的更新週期為T1,其中,該主資料庫伺服器以週期T2發送查詢該鎖的狀態的鎖請求,該備份資料庫以週期T3發送查詢該鎖的狀態的鎖請求,其中,T2小於T1,T3大於或等於T1。
- 如請求項17所述的主資料庫伺服器,其中,該備份資料庫包括熱備資料庫和災備資料庫,其中,該主資料庫和該熱備資料庫位於同一資料中心,該主資料庫和該災備資料庫位於不同的資料中心。
- 如請求項18或19所述的主資料庫伺服器,其中,該主資料庫伺服器還包括:第三發送模組,用於在原主資料庫恢復之後,向該鎖仲裁伺服器發送鎖請求,以便該鎖仲裁伺服器接收該原主資料庫發送的鎖請求,並在該鎖到期之後控制該鎖由該原主資料庫持有以使該原主資料庫恢復為主資料庫,且當前主資料庫恢復為備份資料庫。
- 一種主備資料庫的管理系統,其特徵在於,包括:如請求項9-16之任一項所述的鎖仲裁伺服器;及如請求項17-21之任一項所述的主資料庫伺服器。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
??201611183638.9 | 2016-12-20 | ||
CN201611183638.9A CN107066480B (zh) | 2016-12-20 | 2016-12-20 | 主备数据库的管理方法、系统及其设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
TW201824030A TW201824030A (zh) | 2018-07-01 |
TWI677797B true TWI677797B (zh) | 2019-11-21 |
Family
ID=59619184
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
TW106130943A TWI677797B (zh) | 2016-12-20 | 2017-09-11 | 主備資料庫的管理方法、系統及其設備 |
Country Status (9)
Country | Link |
---|---|
US (1) | US10592361B2 (zh) |
EP (1) | EP3561694B1 (zh) |
JP (1) | JP6905161B2 (zh) |
KR (1) | KR102142233B1 (zh) |
CN (1) | CN107066480B (zh) |
PH (1) | PH12019501392A1 (zh) |
SG (2) | SG10201913120SA (zh) |
TW (1) | TWI677797B (zh) |
WO (1) | WO2018113543A1 (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107066480B (zh) | 2016-12-20 | 2020-08-11 | 创新先进技术有限公司 | 主备数据库的管理方法、系统及其设备 |
US10999392B2 (en) * | 2019-03-01 | 2021-05-04 | Accenture Global Solutions Limited | Message recovery system for computing nodes with replicated databases |
CN110442650A (zh) * | 2019-08-09 | 2019-11-12 | 中国工商银行股份有限公司 | 数据库切换方法、装置、系统、电子设备及存储介质 |
CN110765143B (zh) * | 2019-10-10 | 2022-08-02 | 腾讯科技(深圳)有限公司 | 数据处理方法、装置、服务器和存储介质 |
CN111159156B (zh) * | 2019-12-31 | 2023-04-28 | 杭州迪普科技股份有限公司 | SQLite数据库的备份方法和装置 |
US11379477B2 (en) * | 2020-03-31 | 2022-07-05 | Sap Se | Efficient workload balancing in replicated databases based on result lag computation |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040003317A1 (en) * | 2002-06-27 | 2004-01-01 | Atul Kwatra | Method and apparatus for implementing fault detection and correction in a computer system that requires high reliability and system manageability |
US20060010351A1 (en) * | 2004-07-12 | 2006-01-12 | Infortrend Technology Inc. | Controller capable of self-monitoring, redundant storage system having the same, and method thereof |
US20120233496A1 (en) * | 2011-03-11 | 2012-09-13 | Microsoft Corporation | Fault tolerance in a parallel database system |
CN104778102A (zh) * | 2015-03-27 | 2015-07-15 | 深圳市创梦天地科技有限公司 | 一种主备切换方法及系统 |
TWI529624B (zh) * | 2015-03-19 | 2016-04-11 | Univ Nat Central | Method and system of fault tolerance for multiple servers |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7254736B2 (en) * | 2002-12-18 | 2007-08-07 | Veritas Operating Corporation | Systems and method providing input/output fencing in shared storage environments |
US7284151B2 (en) * | 2003-07-21 | 2007-10-16 | Oracle International Corporation | Conditional data access after database system failure |
US7496701B2 (en) * | 2004-11-18 | 2009-02-24 | International Business Machines Corporation | Managing virtual server control of computer support systems with heartbeat message |
CN100362482C (zh) * | 2005-07-21 | 2008-01-16 | 上海华为技术有限公司 | 一种双机备份实现方法及系统 |
CN100449548C (zh) * | 2007-04-11 | 2009-01-07 | 华为技术有限公司 | 数据库同步方法及系统 |
US9575985B2 (en) * | 2009-12-07 | 2017-02-21 | Novell, Inc. | Distributed lock administration |
US9348883B2 (en) * | 2011-06-01 | 2016-05-24 | Clustrix, Inc. | Systems and methods for replication replay in a relational database |
CN102831038B (zh) * | 2011-06-17 | 2019-03-01 | 中兴通讯股份有限公司 | Enum-dns的容灾方法及enum-dns |
US8719225B1 (en) * | 2012-01-17 | 2014-05-06 | Amazon Technologies, Inc. | System and method for log conflict detection and resolution in a data store |
US9116862B1 (en) * | 2012-01-17 | 2015-08-25 | Amazon Technologies, Inc. | System and method for data replication using a single master failover protocol |
CN102739451B (zh) * | 2012-06-29 | 2014-12-03 | 华为技术有限公司 | 一种主备切换条件更新方法、装置、服务器及系统 |
CN102891849B (zh) * | 2012-09-25 | 2015-07-22 | 北京星网锐捷网络技术有限公司 | 业务数据同步方法、恢复方法及装置和网络设备 |
US9009444B1 (en) * | 2012-09-29 | 2015-04-14 | Emc Corporation | System and method for LUN control management |
CN102945195B (zh) * | 2012-11-26 | 2015-11-18 | 国电南瑞科技股份有限公司 | 一种基于SQLite数据库的主备冗余复制方法 |
US9667490B1 (en) * | 2013-06-05 | 2017-05-30 | Parallels IP Holdings GmbH | Method for high availability of services in cloud computing systems |
US9274902B1 (en) * | 2013-08-07 | 2016-03-01 | Amazon Technologies, Inc. | Distributed computing fault management |
CN103593266B (zh) * | 2013-11-12 | 2016-06-22 | 浪潮(北京)电子信息产业有限公司 | 一种基于仲裁盘机制的双机热备方法 |
US20150339200A1 (en) * | 2014-05-20 | 2015-11-26 | Cohesity, Inc. | Intelligent disaster recovery |
CN106202075B (zh) * | 2015-04-29 | 2021-02-19 | 中兴通讯股份有限公司 | 一种数据库主备切换的方法及装置 |
CN105933379B (zh) * | 2016-04-01 | 2018-10-09 | 浪潮电子信息产业股份有限公司 | 一种业务处理方法、设备及系统 |
CN107066480B (zh) * | 2016-12-20 | 2020-08-11 | 创新先进技术有限公司 | 主备数据库的管理方法、系统及其设备 |
-
2016
- 2016-12-20 CN CN201611183638.9A patent/CN107066480B/zh active Active
-
2017
- 2017-09-11 TW TW106130943A patent/TWI677797B/zh active
- 2017-12-11 KR KR1020197021325A patent/KR102142233B1/ko active IP Right Grant
- 2017-12-11 EP EP17884001.3A patent/EP3561694B1/en active Active
- 2017-12-11 WO PCT/CN2017/115392 patent/WO2018113543A1/zh unknown
- 2017-12-11 SG SG10201913120SA patent/SG10201913120SA/en unknown
- 2017-12-11 JP JP2019533442A patent/JP6905161B2/ja active Active
- 2017-12-11 SG SG10202012899PA patent/SG10202012899PA/en unknown
-
2019
- 2019-04-25 US US16/394,315 patent/US10592361B2/en active Active
- 2019-06-18 PH PH12019501392A patent/PH12019501392A1/en unknown
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040003317A1 (en) * | 2002-06-27 | 2004-01-01 | Atul Kwatra | Method and apparatus for implementing fault detection and correction in a computer system that requires high reliability and system manageability |
US20060010351A1 (en) * | 2004-07-12 | 2006-01-12 | Infortrend Technology Inc. | Controller capable of self-monitoring, redundant storage system having the same, and method thereof |
US20120233496A1 (en) * | 2011-03-11 | 2012-09-13 | Microsoft Corporation | Fault tolerance in a parallel database system |
TWI529624B (zh) * | 2015-03-19 | 2016-04-11 | Univ Nat Central | Method and system of fault tolerance for multiple servers |
CN104778102A (zh) * | 2015-03-27 | 2015-07-15 | 深圳市创梦天地科技有限公司 | 一种主备切换方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
JP6905161B2 (ja) | 2021-07-21 |
US10592361B2 (en) | 2020-03-17 |
SG10201913120SA (en) | 2020-03-30 |
WO2018113543A1 (zh) | 2018-06-28 |
SG10202012899PA (en) | 2021-01-28 |
CN107066480A (zh) | 2017-08-18 |
KR102142233B1 (ko) | 2020-08-07 |
US20190251008A1 (en) | 2019-08-15 |
CN107066480B (zh) | 2020-08-11 |
JP2020502686A (ja) | 2020-01-23 |
TW201824030A (zh) | 2018-07-01 |
PH12019501392A1 (en) | 2020-02-10 |
EP3561694B1 (en) | 2022-06-22 |
EP3561694A1 (en) | 2019-10-30 |
KR20190095443A (ko) | 2019-08-14 |
EP3561694A4 (en) | 2019-12-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
TWI677797B (zh) | 主備資料庫的管理方法、系統及其設備 | |
US11853263B2 (en) | Geographically-distributed file system using coordinated namespace replication over a wide area network | |
WO2016070375A1 (zh) | 一种分布式存储复制系统和方法 | |
US8412790B2 (en) | Method, system and computer readable recording medium for determining major group under split-brain syndrome | |
US9460183B2 (en) | Split brain resistant failover in high availability clusters | |
WO2017177941A1 (zh) | 主备数据库切换方法和装置 | |
US8169856B2 (en) | Time synchronization in cluster systems | |
US9495381B2 (en) | Geographically-distributed file system using coordinated namespace replication over a wide area network | |
CN107241430A (zh) | 一种基于分布式存储的企业级容灾系统及容灾控制方法 | |
WO2021136422A1 (zh) | 状态管理方法、主备应用服务器的切换方法及电子设备 | |
WO2012071920A1 (zh) | 分布式内存数据库的实现方法、系统、令牌控制器及内存数据库 | |
US7669080B2 (en) | Reducing likelihood of data loss during failovers in high-availability systems | |
CN105493474A (zh) | 用于支持用于同步分布式数据网格中的数据的分区级别日志的系统及方法 | |
US20110161724A1 (en) | Data management apparatus, monitoring apparatus, replica apparatus, cluster system, control method and computer-readable medium | |
WO2023082800A1 (zh) | 主节点选择方法、分布式数据库及存储介质 | |
WO2011103763A1 (zh) | 数据容灾的方法、装置及系统 | |
CN104767794A (zh) | 一种分布式系统中的节点选举方法及节点 | |
CN115510156A (zh) | 一种云原生高可用数据库服务提供系统及方法 | |
CN109189854B (zh) | 提供持续业务的方法及节点设备 | |
CN105893176B (zh) | 一种网络存储系统的管理方法和装置 | |
CN108509296B (zh) | 一种处理设备故障的方法和系统 | |
CN105323271B (zh) | 一种云计算系统以及云计算系统的处理方法和装置 | |
CN116455920A (zh) | 一种数据存储方法、系统、计算机设备及存储介质 | |
CN114301763B (zh) | 分布式集群故障的处理方法及系统、电子设备及存储介质 | |
CN102841895A (zh) | 一种处理数据库状态转移的方法和系统 |