MySQL Proxy的二進制版很是方便,下載解壓縮後即用。
解壓縮的目錄爲:
$mysql-proxy_installed_dir (這裏爲/usr/local/mysql-proxy)
|_ bin
|_ include
|_ lib
|_ share
1. 爲mysql-proxy創建配置文件。
如在$mysql-proxy_installed_dir建立文件mysql-proxy.cnf,內容以下:
Text代碼
- [mysql-proxy]
- admin-address = localhost:4041
- admin-username = mytest
- admin-password = 123456
- admin-lua-script = /usr/local/mysql-proxy/lib/mysql-proxy/lua/admin.lua
-
- proxy-backend-addresses=192.168.1.241:3306
注:在windows下我沒發現admin.lua, 關於admin功能我還沒去嘗試。重要的是proxy-backend-addresses配置,上面的例子表示發往mysql proxy的請求將轉發到192.168.1.241這個MySQL服務器的3306端口。
Linux下mysql-proxy.cnf要設置爲0660權限。
2.啓動MySQL Proxy
/usr/local/mysql-proxy/bin/mysql-proxy --defaults-file=/usr/local/mysql-proxy/mysql-proxy.cnf &
默認啓動4040端口。
MySQL的主從同步機制很是方便的解決了高併發讀的應用需求,給Web方面開發帶來了極大的便利。但這種方式有個比較大的缺陷在於MySQL的同步機制 是依賴Slave主動向Master發請求來獲取數據的,並且因爲服務器負載、網絡擁堵等方面的緣由,Master與Slave 之間的數據同步延遲是徹底沒有保證的。短在1秒內,長則幾秒、幾十秒甚至更長都有可能。
因爲數據延遲問題的存在,當應用程序在Master 上進行數據更新,而後又馬上須要從數據庫中讀取數據時,這時候若是應用程序從Slave上取數據(這也是當前Web開發的常規作法),就可能出現讀取不到指望的數據,形成程序運行異常。
解決這個問題有多種方式,好比最簡單的在全部的insert和update以後,強制sleep幾秒鐘。這是很是粗魯的方式,對於更新操做不是很高的中小型系統,此方式基本能解決問題。
另一種方式是應用程序把被更新的數據保存在本機的內存(或者集中式緩存)中,若是在寫入數據完成後須要直接讀取數據,則從本機內存中讀取。這種方式的缺點是極大的增長了應用程序的複雜度,並且可靠性並不能徹底獲得保障。
使用MySQL Proxy能夠很方便的解決這個問題。MySQL Proxy是基於MySQL Client 和 MySQL Server之間的代理程序,可以完成對Client所發請求的監控、修改。從Client角度看,經過Proxy訪問Server和直接訪問 Server沒有任何區別。對於既有的程序而言,只要把直接被訪問的Server的IP地址和端口號換成Proxy的IP地址和端口號就能夠。
MySQL Proxy的工做原理也較簡單。在Proxy啓動時能夠指定Proxy所須要使用的lua腳本,在lua腳本中預先實現6個方法:
* connect_server() // 接收到Client的鏈接請求時調用
* read_handshake() //
* read_auth() // 讀取Client的認證信息時調用
* read_auth_result() // 讀取認證結果時調用
* read_query() // 讀取Client的query請求時調用
* read_query_result() //讀取query結果時調用
當 Proxy接收到Client請求時,在請求的不一樣的階段會調用上面的不一樣方法。這樣Proxy使用者就能夠根據本身的業務需求,自由的實現這6個方法達到目的。
經過在read_query()中加入代碼,咱們能夠截取出當前的請求是insert、update仍是select,而後把 insert和update請求發送到Master中,把select請求發送到Slave中,這樣就解決了讀寫分離的問題。
在解決了讀寫分離後,如何解決同步延遲呢?
方法是在Master上增長一個自增表,這個表僅含有1個的字段。當Master接收到任何數據更新的請求時,均會觸發這個觸發器,該觸發器更新自增表中的記錄。以下圖所示:
mysql_proxy_write
因爲Count_table也參與Mysq的主從同步,所以在Master上做的 Update更新也會同步到Slave上。當Client經過Proxy進行數據讀取時,Proxy能夠先向Master和Slave的 Count_table表發送查詢請求,當兩者的數據相同時,Proxy能夠認定 Master和Slave的數據狀態是一致的,而後把select請求發送到Slave服務器上,不然就發送到Master上。以下圖所示:
mysql_proxy_read
經過這種方式,就能夠比較完美的結果MySQL的同步延遲不可控問題。之因此所「比較完美」,是由於這種方案double了查詢請求,對 Master和Slave構成了額外的壓力。不過因爲Proxy與真實的Mysql Server採用鏈接池的方式鏈接,所以額外的壓力仍是能夠接受的。