haproxy(8)：haproxy代理MySQL要考慮的問題

HaProxy系列文章：http://www.cnblogs.com/f-ck-need-u/p/7576137.html

 

haproxy能夠經過 TCP協議 來代理MySQL。可是兩個問題必須考慮：

1. 後端MySQL的健康檢查問題
   
2. 如何保證事務的持久性(同一個事務中的語句路由到同一個後端)

1.1 健康檢查問題

haproxy默認已支持MySQL的健康檢查，對應的指令爲option mysql-check，瀏覽下該指令語法：

option mysql-check [ user <username> [ post-41 ] ]

其中user是鏈接MySQL時使用的用戶名，post-41是發送一種名爲post v4.1的檢查包。整個過程只檢查haproxy可否鏈接到MySQL。

有時候，僅僅檢查MySQL服務的連通性是不夠的，例如想檢查某個數據庫是否存在，檢查主從複製是否正常，節點是否read_only，某個slave是否嚴重落後於master等等。目前爲止，MySQL組複製(MGR)、Galera已經逐漸普及，haproxy更沒法檢查這兩類集羣的合理性。

這時候須要使用外部腳本，自定義檢查內容並將檢查結果報告給haproxy。固然，藉助腳本實現一些自定義的內部操做也是能夠的。

由於haproxy對http的支持最完善，所以採用httpchk的健康檢查方式，因此使用外部健康檢查腳本時，檢查結果必需要轉換爲haproxy能理解的http狀態碼報告。通常狀況下，健康的結果使用http 200狀態碼錶示，不健康的結果使用Http 503來表示 。

1.1.1 MySQL健康檢查腳本示例

例如，要檢查數據庫mytest是否存在，外部的腳本(假設腳本名爲/usr/bin/mysqlchk.sh)內容大概以下：

#!/bin/bash

# $0:/usr/bin/mysqlchk.sh

mysql_port=3306
mysql_host="localhost"
chk_mysqluser="haproxychk"
chk_mysqlpasswd="haproxychkpassword1!"
mysql=/usr/bin/mysql
to_test_db=mytest

### check 
mysql -u${chk_mysqluser} -p${chk_mysqlpasswd} -h${mysql_host} -P${mysql_port} \ 
-e "show databases;" 2>/dev/null | grep "${to_test_db}" &>/dev/null

### translate the result to report to haproxy 
if [ $? -eq 0 ];then
    # mysql is healthy, return http 200 
    /bin/echo -en "HTTP/1.1 200 OK\r\n" 
    /bin/echo -en "Content-Type: Content-Type: text/plain\r\n" 
    /bin/echo -en "Connection: close\r\n" 
    /bin/echo -en "\r\n" 
    /bin/echo -en "MySQL is running and $to_test_db exists.\r\n" 
    /bin/echo -en "\r\n" 
    sleep 0.1
    exit 0
else
    # mysql is unhealthy, return http 503 
    /bin/echo -en "HTTP/1.1 503 Service Unavailable\r\n" 
    /bin/echo -en "Content-Type: Content-Type: text/plain\r\n" 
    /bin/echo -en "Connection: close\r\n" 
    /bin/echo -en "\r\n" 
    /bin/echo -en "MySQL is down or $to_test_db not exists.\r\n" 
    /bin/echo -en "\r\n" 
    exit 1
fi

執行權限：

chmod +x /usr/bin/mysqlchk.sh

而後，將其放進xinetd中進行管理。

yum -y install xinetd

cat /etc/xinetd.d/mysqlchk
# default: on
# description: /usr/bin/mysqlchk.sh
service mysqlchk
{
        disable = no
        flags           = REUSE
        socket_type     = stream
        type            = UNLISTED
        port            = 9200
        wait            = no
        user            = nobody
        server          = /usr/bin/mysqlchk.sh
        # server_args = arguments pass to mysqlchk.sh
        log_on_failure  += USERID
        only_from       = 0.0.0.0/0
        per_source      = UNLIMITED

而後向/etc/services中添加端口和服務名映射關係：

cat >>/etc/services<<eof
mysqlchk      9200/tcp        #mysqlchk
eof

最後從新啓動xinetd：

service xinetd restart

而後配置haproxy，大概內容以下：

listen mysql-cluster 0.0.0.0:3306
mode tcp
balance roundrobin
option httpchk            # 注意此處是httpchk，不是mysql-check
server db01 10.4.29.100:3306 check port 9200 inter 12000 rise 3 fall 3
server db02 10.4.29.99:3306 check port 9200 inter 12000 rise 3 fall 3
server db03 10.4.29.98:3306 check port 9200 inter 12000 rise 3 fall 3

其實，這個外部檢查腳本是根據Google論壇裏的一篇帖子引伸出來的(源地址：https://groups.google.com/forum/#!topic/codership-team/RO5ZyLnEWKo)。這種檢查方式已經被percona官方採納並進行了完善，放進了percona-xtradb-cluster包中做爲haproxy+PXC的健康檢查腳本。

根據這種模式，可讓haproxy檢查更多類型的服務。

1.2 事務持久性問題

haproxy代理MySQL的時候，事務持久性的問題必須解決。這個事務持久性不是ACID的D(持久性, Durability)，而是transaction persistent，這裏簡單描述一下此處的事務持久性。

客戶端顯式開啓一個事務，而後執行幾個操做，而後提交或回滾。

start transaction
update1...
update2...
insert3...
commit

若是使用代理軟件(例如haproxy)對MySQL進行代理，必需要保證這5個語句全都路由到同一個MySQL節點上，即便後端的MySQL採用的多主模型(組複製、Galera都提供多主模型)，不然事務中各語句分散，輕則返回失敗，重則數據不一致、提交混亂。

這就是transaction persistent的概念：讓同一個事務路由到同一個後端節點。

haproxy如何保證事務持久性？對於非MySQL協議感知的代理(lvs/nginx/haproxy等)，要保證事務持久性，只能經過間接的方法實現，比較通用的方法是在代理軟件上監聽不一樣端口。具體思路以下：

• 1.在haproxy上監聽不一樣端口，例如3307端口的請求做爲寫端口，3306端口的請求做爲讀端口。
  
• 2.從後端MySQL節點中選一個節點(只能是一個)做爲邏輯寫節點，haproxy將3307端口的請求全都路由給這個節點。
  
• 3.能夠在haproxy上配置備用寫節點(backup)，但3307端口在某一時刻，必須只能有一個寫節點。

這樣能保證事務的持久性，也能解決一些樂觀鎖問題。可是，若是後端是多主模型的Galera或MySQL組複製，這樣的代理方式將強制變爲單主模型，雖然是邏輯上的強制。固然，這並不是什麼問題，至少到目前爲止的開源技術，都建議採用單主模型。

如下是haproxy保證事務持久性的配置示例：

listen  haproxy_3306_read_multi
        bind *:3306
        mode tcp
        timeout client  10800s
        timeout server  10800s
        balance leastconn
        option httpchk
        option allbackups
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server galera1 192.168.55.111:3306 check
        server galera2 192.168.55.112:3306 check
        server galera3 192.168.55.113:3306 check
 
listen  haproxy_3307_write_single
        bind *:3307
        mode tcp
        timeout client  10800s
        timeout server  10800s
        balance leastconn
        option httpchk
        option allbackups
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server galera1 192.168.55.111:3306 check
        server galera2 192.168.55.112:3306 check backup
        server galera3 192.168.55.113:3306 check backup

上面的配置經過3306端口和3307端口進行讀寫分離，而且在負責寫的3307中只有一個節點可寫，其他兩個節點做爲backup節點。

對於MySQL的負載來講，更建議採用MySQL協議感知的程序來實現，例如mysql router，proxysql，maxscale，mycat等等數據庫中間件。