本發(fā)明屬于通信領域，特別是涉及一種MySQL數(shù)據(jù)庫集群處理方法及MySQL數(shù)據(jù)庫集群處理系統(tǒng)。

背景技術：

隨著大數(shù)據(jù)時代的到來，數(shù)據(jù)的規(guī)模的不斷增長，數(shù)據(jù)查詢的需求越來越頻繁。用戶對數(shù)據(jù)查詢速度及數(shù)據(jù)查詢服務的不間斷的要求越來越強烈，不希望訪問查詢數(shù)據(jù)的時候等待時間過長，甚至看到“查詢超時”或者“數(shù)據(jù)庫繁忙”的情況。單一的數(shù)據(jù)庫是無法支撐因數(shù)據(jù)快速增長和查詢量快速增長而帶來的存儲和計算強度的相應快速增大。在這種情況下，若購買新的價格更貴，性能更好的數(shù)據(jù)庫服務器做升級而將現(xiàn)有數(shù)據(jù)庫服務器利淘汰，則將必是一種對現(xiàn)有硬件資源的極度浪費,單臺數(shù)據(jù)庫服務器的性能無論多強大，也必然是無法滿足不斷的數(shù)據(jù)量和查詢量的提升，硬件的一次次升級成本和一次次費用投入也將是永無止境的資源浪費，造成原有數(shù)據(jù)庫擴展成本太高，甚至演變成不可擴展的系統(tǒng)，需要推倒重來的困境。

專利文獻CN102594697 A公開一種負載均衡方法，所述負載均衡方法適用于控制和轉發(fā)分離的開放流網(wǎng)絡，包括：接收第一開放流交換機發(fā)送來的與開放流控制器建立連接的請求消息；從連接信息數(shù)據(jù)庫中選擇與開放流交換機建立連接的數(shù)量最少的開放流控制器作為第一開放流控制器，所述連接信息數(shù)據(jù)庫保存至少兩個開放流控制器標識，并且保存所述至少兩個開放流控制器標識對應的開放流控制器與開放流交換機建立連接的數(shù)量；將所述建立連接的請求消息轉發(fā)至所述第一開放流控制器；接收更新消息，更新所述連接信息數(shù)據(jù)庫中所述第一開放流控制器與開放流交換機建立連接的數(shù)量。該專利在開放流網(wǎng)絡中存在多個開放流控制器的情況下，能夠實現(xiàn)開放流控制器之間負載均衡，但該專利無法針對數(shù)據(jù)寫入，更新，刪除請求和占絕大多數(shù)訪問的查詢請求進行分別處理，不能解決數(shù)據(jù)查詢能力的可擴展性，無法防止自身的單點故障導致整個集群無法提供服務，不具備高可用性，擴展靈活性，低擴展成本。

專利文獻CN104036025 A公開的一種基于分布式的海量日志采集系統(tǒng)通過在目標主機上安裝Agent進程，對目標主機的文本、應用程序、數(shù)據(jù)庫等日志信息進行有選擇地定向推送到服務器集群的統(tǒng)一訪問接口，服務器端采用了分布式緩存與實時流處理框架技術；該系統(tǒng)包括數(shù)據(jù)源層、分布式緩存層、分布式存儲與計算層、業(yè)務處理層、可視化展示層和統(tǒng)一調度與管理模塊；數(shù)據(jù)源層，由數(shù)據(jù)采集組件(生產(chǎn)者)模塊對各個節(jié)點上面的文本、應用程序、數(shù)據(jù)庫等進行采集，推送到分布式緩存層；分布式緩存層，由LVS對各個節(jié)點的消息隊列組件進行負載均衡，提供一個統(tǒng)一的接口來接收并寫入數(shù)據(jù)源節(jié)點推送過來的數(shù)據(jù)，等待分布式存儲與計算層的數(shù)據(jù)采集組件(消費者)來讀?。环植际酱鎯εc計算層，提供存儲與計算的功能，包括數(shù)據(jù)采集組件(消費者)模塊、離線計算模塊、實時計算模塊、分布式存儲和搜索引擎；其中，數(shù)據(jù)采集組件(消費者)模塊負責對分布式緩存層進行數(shù)據(jù)讀取；離線計算模塊由Hadoop及其生態(tài)系統(tǒng)組成；實時計算模塊由Storm組成；業(yè)務處理層，提供統(tǒng)計分析和數(shù)據(jù)挖掘的功能與服務，由上層進行調用；可視化展示層，提供普通查詢、全文檢索、報表展示、導入導出等功能；統(tǒng)一調度與管理模塊，對上述5層進行統(tǒng)一的調度與管理，基于工作流，自動化處理。該專利使用了Storm實時流處理框架技術，因此，可以近實時地對Kafka分布式緩存中的消息進行處理并分類，但該專利結構步驟復雜且無法針對數(shù)據(jù)寫入，更新，刪除請求和占絕大多數(shù)訪問的查詢請求進行分別處理，不能解決數(shù)據(jù)查詢能力的可擴展性，無法防止自身的單點故障導致整個集群無法提供服務，不具備高可用性，擴展靈活性，低擴展成本。

專利文獻CN1560742 A公開的一種基于改進的linux虛擬服務器架構的開放式網(wǎng)絡計算平臺，該計算平臺包括基于改進的linux虛擬服務器架構的服務器系統(tǒng)(20)和貢獻空閑計算資源的志愿機系統(tǒng)(21)；服務器系統(tǒng)(20)包括前端機(6)和m臺昊宇服務器(7.1，……，7.m)，m為正整數(shù)；志愿機系統(tǒng)(21)包括n臺昊宇志愿機(8.1，……，8.n)，n為正整數(shù)；前端機(6)包括負載均衡模塊(18)和前端機備份模塊(19)；其中，負載均衡模塊(18)當昊宇志愿機將請求發(fā)送給前端機時，將請求轉發(fā)到昊宇服務器的調度模塊(13)上；前端機備份模塊(19)根據(jù)自適應策略建立并維護昊宇服務器之間的備份關系向量表，并將該備份關系向量表發(fā)送給服務器備份模塊(12)；昊宇服務器(7)包括存儲系統(tǒng)(9)、應用模塊(10)、監(jiān)控模塊(11)、服務器備份模塊(12)和調度模塊(13)，其中，存儲系統(tǒng)包括數(shù)據(jù)庫系統(tǒng)和文件系統(tǒng)；應用模塊(10)用于接收客戶提交的應用，并將應用劃分成計算量小的任務，再通過命令將應用信息和任務信息存入數(shù)據(jù)庫系統(tǒng)，應用的二進制代碼和任務的數(shù)據(jù)文件存入文件系統(tǒng)；監(jiān)控模塊(11)用于讀取數(shù)據(jù)庫系統(tǒng)中的信息，處理后加以顯示，以監(jiān)控昊宇服務器的運轉狀況；服務器備份模塊(12)根據(jù)備份關系向量表，將存儲系統(tǒng)中的數(shù)據(jù)庫信息和文件信息備份到對應的服務器上；調度模塊(13)當昊宇志愿機中的通信模塊(16)請求計算任務時，根據(jù)應用模塊(10)寫入數(shù)據(jù)庫系統(tǒng)中的任務信息，統(tǒng)一調度任務，通過昊宇志愿機中的通信模塊(16)分配給志愿機執(zhí)行；還用于在通信模塊(16)返回計算結果以后，將結果文件存放到文件系統(tǒng)中，并修改數(shù)據(jù)庫系統(tǒng)中的任務信息；昊宇志愿機(8)包括志愿者接口模塊(14)、控制模塊(15)、通信模塊(16)和計算模塊(17)；其中，志愿者接口模塊(14)用于實時監(jiān)聽并執(zhí)行志愿者發(fā)出的命令，根據(jù)命令修改配置文件中相應的項；控制模塊(15)循環(huán)根據(jù)配置文件的設置，當啟動計算的條件滿足時，啟動通信模塊(16)，向昊宇服務器請求計算任務，當調度模塊(13)返回計算任務后，啟動計算模塊(17)，以最低優(yōu)先級計算任務，在計算過程中通信模塊(16)周期性地向調度模塊(13)發(fā)送“alive”信息，并將計算結果通過通信模塊(16)返回給調度模塊(13)。該專利具有LVS架構的一切優(yōu)良特性，但該專利結構步驟復雜且無法針對數(shù)據(jù)寫入，更新，刪除請求和占絕大多數(shù)訪問的查詢請求進行分別處理，無法防止自身的單點故障導致整個集群無法提供服務，不具備擴展靈活性和低擴展成本。

技術實現(xiàn)要素：

關于本發(fā)明所要解決的技術問題，其具體需求如下：針對數(shù)據(jù)寫入，更新，刪除請求和占絕大多數(shù)訪問的查詢請求進行分別處理，解決數(shù)據(jù)查詢能力的可擴展性，防止自身的單點故障導致整個集群無法提供服務，具備高可用性，擴展靈活性，低擴展成本。

在背景技術部分中公開的上述信息僅僅用于增強對本發(fā)明背景的理解，因此可能包含不構成在本國中本領域普通技術人員公知的現(xiàn)有技術的信息。

本發(fā)明的目的是通過以下技術方案予以實現(xiàn)。

根據(jù)本發(fā)明的一方面，一種MySQL數(shù)據(jù)庫集群處理方法包括以下步驟：

在第一步驟中，MySQL數(shù)據(jù)庫集群包括一個用于寫入的主MySQL數(shù)據(jù)庫和多個用于查詢的從MySQL數(shù)據(jù)庫，用戶通過web訪問所述MySQL數(shù)據(jù)庫集群。

在第二步驟中，當web訪問為寫入、更新或刪除請求時，所述主MySQL數(shù)據(jù)庫響應該請求，當web訪問為查詢請求時，包括主LVS和從LVS的負載均衡器接收到查詢請求后，虛擬IP地址監(jiān)控主LVS和從LVS是否可用。

在第三步驟中，Keepalived模塊監(jiān)測從MySQL數(shù)據(jù)庫對應的數(shù)據(jù)庫查詢服務器是否可用，自動把存在問題的數(shù)據(jù)庫查詢服務器踢出集群，并按照預定的權重分配查詢任務。

在第四步驟中，接收所述查詢任務的數(shù)據(jù)庫查詢服務器查詢并將查詢結果返回給用戶。

優(yōu)選地，在第三步驟中，Keepalived模塊監(jiān)測主LVS是否可用，然后Keepalived模塊中的調度器根據(jù)各個數(shù)據(jù)庫查詢服務器的負載情況動態(tài)地選擇一臺數(shù)據(jù)庫查詢服務器，將請求報文的數(shù)據(jù)幀的目標MAC地址改為所述數(shù)據(jù)庫查詢服務器的MAC地址。

優(yōu)選地，在第三步驟中，所述數(shù)據(jù)庫查詢服務器接收到請求時，目標IP為所述虛擬IP地址，然后所述數(shù)據(jù)庫查詢服務器響應請求，之后根據(jù)其路由信息將響應的數(shù)據(jù)包發(fā)送回給用戶，并且源IP地址為虛擬IP地址。

優(yōu)選地，在第二步驟中，負載均衡器為DNS混合負載均衡器、VS/TUN或VS/DR。

優(yōu)選地，在第三步驟中，當存在問題的數(shù)據(jù)庫查詢服務器工作正常后，Keepalived模塊自動將其加入到MySQL數(shù)據(jù)庫集群。

優(yōu)選地，多個用于查詢的從MySQL數(shù)據(jù)庫實時同步所述主MySQL數(shù)據(jù)庫。

優(yōu)選地，在第三步驟中，所述數(shù)據(jù)庫查詢服務器為云端服務器。

根據(jù)本發(fā)明的另一方面，一種實施所述的MySQL數(shù)據(jù)庫集群處理方法的MySQL數(shù)據(jù)庫集群處理系統(tǒng)包括服務器群、負載均衡器和Keepalived模塊，所述服務器群包括用于承載主MySQL數(shù)據(jù)庫的主服務器和多個用于承載從MySQL數(shù)據(jù)庫的數(shù)據(jù)庫查詢服務器，負載均衡器包括主LVS和從LVS，Keepalived模塊中設有調度器。

優(yōu)選地，處理系統(tǒng)包括用于執(zhí)行命令的處理器、用于通信的通信總線和存儲命令的存儲器。

優(yōu)選地，所述處理器是通用處理器、數(shù)字信號處理器、專用集成電路ASIC，現(xiàn)場可編程門陣列FPGA、模擬電路或數(shù)字電路，所述存儲器包括一個或多個只讀存儲器ROM、隨機存取存儲器RAM、快閃存儲器或電子可擦除可編程只讀存儲器EEPROM。

上述說明僅是本發(fā)明技術方案的概述，為了能夠使得本發(fā)明的技術手段更加清楚明白，達到本領域技術人員可依照說明書的內容予以實施的程度，并且為了能夠讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，下面以本發(fā)明的具體實施方式進行舉例說明。

附圖說明

通過閱讀下文優(yōu)選的具體實施方式中的詳細描述，本發(fā)明各種其他的優(yōu)點和益處對于本領域普通技術人員將變得清楚明了。說明書附圖僅用于示出優(yōu)選實施方式的目的，而并不認為是對本發(fā)明的限制。顯而易見地，下面描述的附圖僅僅是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。而且在整個附圖中，用相同的附圖標記表示相同的部件。

在附圖中：

圖1是根據(jù)本發(fā)明一個實施例的MySQL數(shù)據(jù)庫集群處理方法的步驟示意圖；

圖2是根據(jù)本發(fā)明一個實施例的實施MySQL數(shù)據(jù)庫集群處理方法的邏輯流程圖；

圖3是根據(jù)本發(fā)明一個實施例的實施MySQL數(shù)據(jù)庫集群處理方法的工作流程圖。

圖4是根據(jù)本發(fā)明一個實施例的實施MySQL數(shù)據(jù)庫集群處理方法的MySQL數(shù)據(jù)庫集群處理系統(tǒng)的結構示意圖。

圖5是根據(jù)本發(fā)明一個實施例的實施MySQL數(shù)據(jù)庫集群處理方法的MySQL數(shù)據(jù)庫集群處理系統(tǒng)的網(wǎng)絡拓撲圖。

以下結合附圖和實施例對本發(fā)明作進一步的解釋。

具體實施方式

下面將參照附圖更詳細地描述本發(fā)明的具體實施例。雖然附圖中顯示了本發(fā)明的具體實施例，然而應當理解，可以以各種形式實現(xiàn)本發(fā)明而不應被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本發(fā)明，并且能夠將本發(fā)明的范圍完整的傳達給本領域的技術人員。

需要說明的是，在說明書及權利要求當中使用了某些詞匯來指稱特定組件。本領域技術人員應可以理解，技術人員可能會用不同名詞來稱呼同一個組件。本說明書及權利要求并不以名詞的差異來作為區(qū)分組件的方式，而是以組件在功能上的差異來作為區(qū)分的準則。如在通篇說明書及權利要求當中所提及的“包含”或“包括”為一開放式用語，故應解釋成“包含但不限定于”。說明書后續(xù)描述為實施本發(fā)明的較佳實施方式，然所述描述乃以說明書的一般原則為目的，并非用以限定本發(fā)明的范圍。本發(fā)明的保護范圍當視所附權利要求所界定者為準。

為便于對本發(fā)明實施例的理解，下面將結合附圖以幾個具體實施例為例做進一步的解釋說明，且各個附圖并不構成對本發(fā)明實施例的限定。

圖1為本發(fā)明的一個實施例的MySQL數(shù)據(jù)庫集群處理方法的步驟示意圖，本發(fā)明實施例將結合圖1進行具體說明。

如圖1所示，本發(fā)明的一個實施例提供了一種MySQL數(shù)據(jù)庫集群處理方法，MySQL數(shù)據(jù)庫集群處理方法包括以下步驟：

在第一步驟S1中，MySQL數(shù)據(jù)庫集群包括一個用于寫入的主MySQL數(shù)據(jù)庫和多個用于查詢的從MySQL數(shù)據(jù)庫，用戶通過web訪問所述MySQL數(shù)據(jù)庫集群。

在第二步驟S2中，當web訪問為寫入、更新或刪除請求時，所述主MySQL數(shù)據(jù)庫響應該請求，當web訪問為查詢請求時，包括主LVS和從LVS的負載均衡器LVS接收到查詢請求后，虛擬IP地址VIP監(jiān)控主LVS和從LVS是否可用。

在第三步驟S3中，Keepalived模塊監(jiān)測從MySQL數(shù)據(jù)庫對應的數(shù)據(jù)庫查詢服務器是否可用，自動把存在問題的數(shù)據(jù)庫查詢服務器踢出集群，并按照預定的權重分配查詢任務。

在第四步驟S4中，接收所述查詢任務的數(shù)據(jù)庫查詢服務器查詢并將查詢結果返回給用戶。

在一個實施例中，本發(fā)明的MySQL數(shù)據(jù)庫集群處理方法以實現(xiàn)Linux虛擬服務器LVS+keeplived負載均衡數(shù)據(jù)mysql運維，根據(jù)web請求觸發(fā)數(shù)據(jù)查詢，分發(fā)給后端的數(shù)據(jù)庫mysql查詢服務器集群處理數(shù)據(jù)查詢任務。主從數(shù)據(jù)庫mysql查詢LVS通過keepalived相互作健康監(jiān)測，接收對應的查詢請求，按keepalived的權重設置分配查詢任務到后端的數(shù)據(jù)庫mysql查詢集群內對應的服務器。通過keepalived對后端的數(shù)據(jù)庫mysql查詢服務器的狀態(tài)，如果有一臺數(shù)據(jù)庫mysql查詢服務器死機，或工作出現(xiàn)故障，Keepalived將檢測到，并將有故障的服務器從LVS系統(tǒng)中踢除，同時使用其他服務器代替該服務器的工作，當該數(shù)據(jù)庫mysql查詢服務器恢復正常后，Keepalived自動將該數(shù)據(jù)庫mysql查詢服務器自動加入到該LVS系統(tǒng)中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是下線修復故障的服務器。MySQL是一個關系型數(shù)據(jù)庫管理系統(tǒng)，MySQL是一種關聯(lián)數(shù)據(jù)庫管理系統(tǒng)，關聯(lián)數(shù)據(jù)庫將數(shù)據(jù)保存在不同的表中，而不是將所有數(shù)據(jù)放在一個大倉庫內，這樣就增加了速度并提高了靈活性。MySQL所使用的SQL語言是用于訪問數(shù)據(jù)庫的最常用標準化語言。MySQL可采用雙授權政策，由于其體積小、速度快、總體擁有成本低，尤其是開放源碼這一特點，一般中小型網(wǎng)站的開發(fā)都選擇MySQL作為網(wǎng)站數(shù)據(jù)庫。由于其性能卓越，搭配PHP和Apache，Nginx可組成良好的開發(fā)環(huán)境。

圖2是根據(jù)本發(fā)明一個實施例的實施MySQL數(shù)據(jù)庫集群處理方法的邏輯流程圖，步驟1：用戶通過web訪問觸發(fā)數(shù)據(jù)庫查詢請求。步驟2：負載均衡的VIP會相互監(jiān)控查詢庫的主LVS和查詢庫的從LVS是否可用。步驟3：無論是查詢庫的主LVS還是查詢庫的從LVS接到用戶的查詢請求后，都會對后端的數(shù)據(jù)庫mysql查詢服務器做健康監(jiān)測，自動把有問題的數(shù)據(jù)庫mysql查詢服務器踢出集群，并按照keepalived設置的權重分配查詢任務。步驟4：數(shù)據(jù)庫mysql查詢服務器把查詢結果返回給用戶。

本發(fā)明的優(yōu)選的實施方式中，在第三步驟S3中，Keepalived模塊監(jiān)測主LVS是否可用，然后Keepalived模塊中的調度器根據(jù)各個數(shù)據(jù)庫查詢服務器的負載情況動態(tài)地選擇一臺數(shù)據(jù)庫查詢服務器，將請求報文的數(shù)據(jù)幀的目標MAC地址改為所述數(shù)據(jù)庫查詢服務器的MAC地址。

本發(fā)明的優(yōu)選的實施方式中，在第三步驟S3中，所述數(shù)據(jù)庫查詢服務器接收到請求時，目標IP為所述虛擬IP地址VIP，然后所述數(shù)據(jù)庫查詢服務器響應請求，之后根據(jù)其路由信息將響應的數(shù)據(jù)包發(fā)送回給用戶，并且源IP地址為虛擬IP地址VIP。

本發(fā)明的優(yōu)選的實施方式中，在第二步驟S2中，負載均衡器LVS為DNS混合負載均衡器、VS/TUN或VS/DR。

本發(fā)明的優(yōu)選的實施方式中，在第三步驟S3中，當存在問題的數(shù)據(jù)庫查詢服務器工作正常后，Keepalived模塊自動將其加入到MySQL數(shù)據(jù)庫集群。

本發(fā)明的優(yōu)選的實施方式中，多個用于查詢的從MySQL數(shù)據(jù)庫實時同步所述主MySQL數(shù)據(jù)庫。

本發(fā)明的優(yōu)選的實施方式中，在第三步驟S3中，所述數(shù)據(jù)庫查詢服務器為云端服務器。

圖3是根據(jù)本發(fā)明一個實施例的實施MySQL數(shù)據(jù)庫集群處理方法的工作流程圖。如圖3所示，在一個實施例中，將報文直接路由給目標真實服務器。在DR模式中，首先利用Keepalived模塊2的健康監(jiān)測機制監(jiān)測主的Lvs是否健康作出Lvs的高可用性，然后通過keepalived調度器根據(jù)各個真實服務器的負載情況，連接數(shù)多少等，動態(tài)地選擇一臺服務器，不修改目標IP地址和目標端口，也不封裝IP報文，而是將請求報文的數(shù)據(jù)幀的目標MAC地址改為真實服務器的MAC地址。然后再將修改的數(shù)據(jù)幀在服務器組的局域網(wǎng)上發(fā)送。因為數(shù)據(jù)幀的MAC地址是真實服務器的MAC地址，并且又在同一個局域網(wǎng)。那么根據(jù)局域網(wǎng)的通訊原理，真實復位是一定能夠收到由LVS+KEEPALIVED發(fā)出的數(shù)據(jù)包。真實服務器接收到請求數(shù)據(jù)包的時候，解開IP包頭查看到的目標IP是VIP,，此時只有自己的IP符合目標IP才會接收進來，所以我們需要在本地的回環(huán)借口上面配置VIP。另：由于網(wǎng)絡接口都會進行ARP廣播響應，但集群的其他機器都有這個VIP的lo接口，都響應就會沖突。所以我們需要把真實服務器的lo接口的ARP響應關閉掉。然后真實服務器做成請求響應，之后根據(jù)自己的路由信息將這個響應數(shù)據(jù)包發(fā)送回給客戶，并且源IP地址還是VIP。

數(shù)據(jù)流的整個流程如下：

1、通過在調度器LVS+KEEPALIVED上修改數(shù)據(jù)包的目的MAC地址實現(xiàn)轉發(fā)。注意源地址仍然是CIP，目的地址仍然是VIP地址。

2、請求的報文經(jīng)過調度器，而RS響應處理后的報文無需經(jīng)過調度器LVS+KEEPALIVED，因此并發(fā)訪問量大時使用效率很高。

3、因為DR模式是通過MAC地址改寫機制實現(xiàn)轉發(fā)，因此所有RS節(jié)點和調度器LVS+KEEPALIVED只能在一個局域網(wǎng)里面。

4、RS主機需要綁定VIP地址在LO接口上，并且需要配置ARP抑制。

5、RS節(jié)點的默認網(wǎng)關不需要配置成LVS+KEEPALIVED，而是直接配置為上級路由的網(wǎng)關，能讓RS直接出網(wǎng)就可以。

6、由于DR模式的調度器僅做MAC地址的改寫，所以調度器LVS+KEEPALIVED就不能改寫目標端口，那么RS服務器就得使用和VIP相同的端口提供服務。

圖4是根據(jù)本發(fā)明一個實施例的實施MySQL數(shù)據(jù)庫集群處理方法的MySQL數(shù)據(jù)庫集群處理系統(tǒng)的結構示意圖。實施所述的MySQL數(shù)據(jù)庫集群處理方法的MySQL數(shù)據(jù)庫集群處理系統(tǒng)包括服務器群1、負載均衡器LVS和Keepalived模塊2，所述服務器群1包括用于承載主MySQL數(shù)據(jù)庫的主服務器3和多個用于承載從MySQL數(shù)據(jù)庫的數(shù)據(jù)庫查詢服務器4，負載均衡器LVS包括主LVS5和從LVS6，Keepalived模塊2中設有調度器7。

本發(fā)明的優(yōu)選的實施方式中，處理系統(tǒng)包括用于執(zhí)行命令的處理器、用于通信的通信總線和存儲命令的存儲器。

本發(fā)明的優(yōu)選的實施方式中，Keepalived模塊主要使用VRRP協(xié)議來保存鏈路的高可用性。而VRRP(Virtual Router Redundancy Protocol)協(xié)議本身是用于實現(xiàn)路由器冗余的協(xié)議。

本發(fā)明的優(yōu)選的實施方式中，所述處理器是通用處理器、數(shù)字信號處理器、專用集成電路ASIC，現(xiàn)場可編程門陣列FPGA、模擬電路或數(shù)字電路，所述存儲器包括一個或多個只讀存儲器ROM、隨機存取存儲器RAM、快閃存儲器或電子可擦除可編程只讀存儲器EEPROM。

為了進一步理解本發(fā)明，圖5是根據(jù)本發(fā)明一個實施例的實施MySQL數(shù)據(jù)庫集群處理方法的MySQL數(shù)據(jù)庫集群處理系統(tǒng)的網(wǎng)絡拓撲圖。如圖5所示，用戶發(fā)出查詢請求，負載均衡層包括負載均衡器LVS和Keepalived模塊2，負載均衡層還可以包括備份的負載均衡器LVS和Keepalived模塊2，負載均衡層通過交換機將查詢請求連接到數(shù)據(jù)庫查詢層，數(shù)據(jù)庫查詢層可包括多個從MySQL數(shù)據(jù)庫。

本發(fā)明首先解決了多臺mysql數(shù)據(jù)庫的數(shù)據(jù)寫入，更新，刪除，查詢和數(shù)據(jù)的一致性問題。其次解決了數(shù)據(jù)查詢能力的可擴展性，同時為了防止LVS負載均衡器自身的單點故障導致整個“mysql-查詢”集群無法提供服務，因此還得利用Keepalived模塊實現(xiàn)LVS負載均衡器的高可用性，負載均衡能夠充分的利用現(xiàn)有的網(wǎng)絡結構，在網(wǎng)絡結構的基礎之上擴展“mysql-查詢”集群的帶寬和網(wǎng)絡設備、加強數(shù)據(jù)查詢的可用性及快速性、提高數(shù)據(jù)查詢處理能力，從而提供了一種廉價有效透明的方法，使mysql-查詢集群具有高可用性，擴展靈活性，擴展成本低等特點。

盡管以上結合附圖對本發(fā)明的實施方案進行了描述，但本發(fā)明并不局限于上述的具體實施方案和應用領域，上述的具體實施方案僅僅是示意性的、指導性的，而不是限制性的。本領域的普通技術人員在本說明書的啟示下和在不脫離本發(fā)明權利要求所保護的范圍的情況下，還可以做出很多種的形式，這些均屬于本發(fā)明保護之列。