程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> 基於MySQL的數據庫集群系統的實現(1)

基於MySQL的數據庫集群系統的實現(1)

編輯:MySQL綜合教程

第一節 數據庫集群技術的現狀

目前數據庫集群系統應用得比較成功,應用范圍比較廣泛的是:Oracle公司的Oracle9與IBM公司DB2。Oracle9采用Shared-storage的技術,DB2選擇了Shared-nothing的技術,二者各有長短。

最新的數據庫集群系統的理論基礎是分布式計算,將數據分布到每個節點,所有的計算節點並行處理數據,將結果匯總。這樣的方式無疑是最完美的。但是目前仍然不能實現全部的功能。


對於Shared-storage以及Shared-nothing的技術請參考Oracle以及IBM網站上的相關資料。

第二節 目前數據庫應用狀況

目前數據庫應用狀況大致分為兩類,第一類是數據量在100G以下,數據庫訪問頻繁,請求密集。主要是Web APP類型的應用,例如:網站,論壇等。這些Web APP類型的應用訪問數據庫的特點是:訪問頻繁,數據庫每秒鐘要接受幾千次以上的查詢,需要經常追加數據,同時對數據的響應速度要求比較高。另一類是用於科學計算、存儲歷史數據的應用,數據量往往達到幾百G。這些應用訪問數據庫的特點是:多為查詢操作,數據都是分批、定時、集中倒入數據庫,數據庫的記錄非常多,積累了大量的數據,對數據庫的響應速度沒有太高要求。

第三節 暴露出來的問題

第一類應用,由於訪問比較頻繁,而且為了支持更多的訪問,Web Server一般都使用了負載均衡的集群,但是對於數據庫來說,由於無法實現集群操作,每秒鐘的請求不斷增加,隨著服務器負載的增加,響應單個請求的速度越來越慢,如果庫文件比較大,出現寫操作的時候還會出現鎖表時間過長等影響訪問效率的事情。

第二類應用,主要是數據文件太大,每次處理數據都需要大量的時間,如果寫錯一個語句就需要花幾個小時來重做查詢。

第四節 如何解決

首先應當從硬件、軟件、程序、索引、SQL語句這幾個方面進行優化,如果仍然不能解決問題,我們就要考慮數據庫系統的集群並行處理)了。

對於第一類的應用,在數據庫服務器正常運行,負載不高的情況下,應用對數據庫系統的狀況還是滿意的。但是數據庫系統負載過高之後,就會出現完成請求的時間加長,達不到系統的要求時間。既然負載是由於過多的請求造成的,我們就采取分擔請求的方式,讓一部分的請求去訪問另外一台服務器,讓單台服務器的負載降低,從而解決問題。

對於第二類的應用,就需要分布式計算的系統來解決了,一般的系統是無能為力了。

第五節 針對於"Linux+Apache+PHP+MySQL"的第一類應用問題的解決方式

一個實際案例的解決:

我在工作當中遇到了這樣的問題,我們的Web Server是Linux+Apache+Php的三台機器組成的集群,MySQL運行在SUN450,2G內存的平台上。由於WEB的訪問量在高峰的時候幾乎滿負荷運轉,LoadAvg(就是一分鐘之內處於Running狀態的進程數量)都在10-20之間,反映出來就是大量的請求都在訪問數據庫的時候被掛住了,導致一個請求沒有完成,下一個請求又進來,最後惡性循環。LoadAvg會在瞬間飙升至800以上。數據庫那邊就更糟糕了,LoadAvg達到 300多,數據庫的線程非常多,CPU忙於切換線程狀態,這個時候除非Restart MySQL,否則怎麼都不會好。在對SQL語句優化完成後還是不能很好的解決問題,我們增加了一台數據庫服務器,通過MySQL的數據同步機制,讓兩台數據庫上的數據保持同步,修改了一部分只會發生讀取操作的php程序,讓這些程序連接另外一台數據庫,算是把負載分離出去一部分,問題得到了初步的解決。但是後來業務做大,我們又增加了多台服務器,修改了很多程序,分離他們對數據庫的讀取操作,訪問不同的服務器。

第六節 MySQL-HA-Proxy方案的提出

通過修改程序的方式實現將系統的負載分離,是件很痛苦的事情,工程浩大,而且不能弄錯,因為除了主服務器可以寫入、修改數據,而其它的服務器只能通過數據同步更新自身的數據,所以如果你對那些數據庫進行了寫操作,結果將是災難性的。

如果我們能夠有一個程序分揀SQL語句,根據他的類型讀取/寫入),分別傳送給不同的服務器,然後再將結果返回。采用一種類似HTTP的PROXY的方式,這樣我們就不需要通過修改源程序的方式來分擔負載了,如果再能夠根據服務器的負載狀況,或者是表的狀態可用/鎖定),來判斷應該將這個請求分配到哪台服務器,那就比我們修改源程序所能達到的效果還要好。

第七節 MySQL Client 與 Server之間如何通信

四處尋找,也沒有找到一篇關於Mysql通訊協議的文章,看來只有分析Mysql的源程序了。於是找來mysql 3.23.49的代碼,打開sniffer工具。MySQL的通訊協議可能變更過多次,在3.23.49的版本裡面,通訊協議的版本竟然是10。

簡單的分析了一下通訊協議,現在規整如下,有些地方還不是很完善,由於我實在沒有太多的時間仔細研讀mysql的代碼,目前我只了解到了這些。

Server 對 Client 請求的響應數據格式:

偏移 區域 類型 長度(byte) 說明 0 HEAD Data Length 3   1   2   3   FLAG 1 =0普通信息
=1多段信息
=2認證返回
>2段結束字 4 DATA CMD Code 1   5   Message DataLength - 1  

當FLAG=0 , 2的時候 CMD Code 與 Message 的定義

CMDCode 類型 Message的結構 00 狀態碼 偏移 類型 Length(byte)       0 Affect rows 2   0A 服務器版本號 偏移 類型 Length(byte)     只有在剛剛連接上Server的時候有效,Server會馬上返回一個數據節段的信息 0 VersionString 8 end of '\0'   8 Session ID 4 32bits   12 UnKnown 11             FF 當出現錯誤的時候返回信息 偏移 類型 Length(byte)       0 ErrCode 2       2 ErrMsg END   FE 多段信息傳輸的結束 空


  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved