《MaxScale：實現MySQL讀寫分離與負載均衡的中間件利器》要點：
本文介紹了MaxScale：實現MySQL讀寫分離與負載均衡的中間件利器，希望對您有用。如果有疑問，可以聯系我們。

1、MaxScale 是干什么的?

配置好了MySQL的主從復制結構后,我們希望實現讀寫分離,把讀操作分散到從服務器中,并且對多個從服務器能實現負載均衡.

讀寫分離和負載均衡是MySQL集群的基礎需求,MaxScale 就可以幫著我們方便的實現這些功能.

2、MaxScale 的基礎構成

MaxScale 是MySQL的兄弟公司 MariaDB 開發的,現在已經發展得非常成熟.MaxScale 是插件式結構,允許用戶開發適合自己的插件.

MaxScale 目前提供的插件功能分為5類：

• 認證插件

  提供了登錄認證功能,MaxScale 會讀取并緩存數據庫中 user 表中的信息,當有連接進來時,先從緩存信息中進行驗證,如果沒有此用戶,會從后端數據庫中更新信息,再次進行驗證

• 協議插件

  包括客戶端連接協議,和連接數據庫的協議

• 路由插件?

  決定如何把客戶端的請求轉發給后端數據庫服務器,讀寫分離和負載均衡的功能就是由這個模塊實現的

• 監控插件

  對各個數據庫服務器進行監控,例如發現某個數據庫服務器響應很慢,那么就不向其轉發請求了

• 日志和過濾插件

  提供簡單的數據庫防火墻功能,可以對SQL進行過濾和容錯

3、MaxScale 的安裝使用

例如有 3 臺數據庫服務器,是一主二從的結構.

過程概述

(1)配置好集群環境

(2)下載安裝 MaxScale

(3)配置 MaxScale,添加各數據庫信息

(4)啟動 MaxScale,查看是否正確連接數據庫

(5)客戶端連接 MaxScale,進行測試

詳細過程

(1)配置一主二從的集群環境

準備3臺服務器,安裝MySQL,配置一主二從的復制結構.

(2)安裝 MaxScale

最好在另一臺服務器上安裝,如果資源不足,可以和某個MySQL放在一起.

MaxScale?的下載地址：https://downloads.mariadb.com/files/MaxScale

根據自己的服務器選擇合適的安裝包.

以 centos 7 為例 安裝步驟如下：

yum install libaio.x86_64 libaio-devel.x86_64 novacom-server.x86_64 libedit -yrpm -ivh maxscale-1.4.3-1.centos.7.x86_64.rpm

(3)配置 MaxScale

在開始配置之前,需要在 master 中為 MaxScale 創建兩個用戶,用于監控模塊和路由模塊.

創建監控用戶

mysql> create user scalemon@’%’ identified by “111111”;mysql> grant replication slave, replication client on *.* to scalemon@’%’;

創建路由用戶

mysql> create user maxscale@’%’ identified by “111111”;mysql> grant select on mysql.* to maxscale@’%’;

用戶創建完成后,開始配置

vi /etc/maxscale.cnf

找到 [server1] 部分,修改其中的 address 和 port,指向 master 的 IP 和端口.

復制2次 [server1] 的整塊兒內容,改為 [server2] 與 [server3],同樣修改其中的 address 和 port,分別指向 slave1 和 slave2：

找到 [MySQL Monitor] 部分,修改 servers 為 server1,server2,server3,修改 user 和 passwd 為之前創建的監控用戶的信息(scalemon,111111).

找到 [Read-Write Service] 部分,修改 servers 為 server1,server2,server3,修改 user 和 passwd 為之前創建的路由用戶的信息(maxscale,111111).

由于我們使用了 [Read-Write Service],需要刪除另一個服務 [Read-Only Service],刪除其整塊兒內容即可.

配置完成,保存并退出編輯器.

(4)啟動 MaxScale

執行啟動命令

maxscale –config=/etc/maxscale.cnf

查看 MaxScale 的響應端口是否已經就緒

netstat -ntelp

• 4006 是連接 MaxScale 時使用的端口
• 6603 是 MaxScale 管理器的端口

登錄 MaxScale 管理器,查看一下數據庫連接狀態,默認的用戶名和密碼是 admin/mariadb.

maxadmin –user=admin –password=mariadb

MaxScale> list servers

可以看到,MaxScale 已經連接到了 master 和 slave.

(5)測試

先在 master 上創建一個測試用戶

mysql> grant ALL PRIVILEGES on *.* to rtest@”%” Identified by “111111”;

使用 Mysql 客戶端到連接 MaxScale

mysql -h MaxScale所在的IP -P 4006 -u rtest -p111111

執行查看數據庫服務器名的操作來知道當前實際所在的數據庫：

開啟事務后,就自動路由到了 master,普通的查詢操作,是在 slave上

MaxScale 的配置完成了.

4、MaxScale 在?slave 有故障后的處理

前面已經介紹了 MaxScale可以實現MySQL的讀寫分離和讀負載均衡,那么當 slave 出現故障后,MaxScale 會如何處理呢?

例如有 3 臺數據庫服務器,一主二從的結構,數據庫名稱分別為 master, slave1, slave2.

現在我們實驗以下兩種情況：

(1)當一臺從服務器( slave1 或者 slave2 )出現故障后,查看 MaxScale 如何應對,及故障服務器重新上線后的情況

(2)當兩臺從服務器( slave1 和 slave2 )都出現故障后,查看 MaxScale 如何應對,及故障服務器重新上線后的情況

準備

為了更深入的查看 MaxScale 的狀態,需要把 MaxScale 的日志打開：

修改配置文件

vi /etc/maxscale.cnf

?找到 [maxscale] 部分,這里用來進行全局設置,在其中添加日志.

配置?

log_info=1logdir=/tmp/

通過開啟 log_info 級別,可以看到 MaxScale 的路由日志.

修改配置后,重啟 MaxScale .

實驗過程

1、單個 slave 故障的情況

?初始狀態是一切正常.

停掉 slave2 的復制,登錄 slave2 的 mysql 執行.

mysql> stop slave;

查看 MaxScale 服務器狀態

slave2 已經失效了.

查看日志信息

cat /tmp/maxscale1.log

尾部顯示：

2016-08-15 12:26:02 ? notice : Server changed state: slave2[172.17.0.4:3306]: lost_slave

提示 slave2 已經丟失.

查看客戶端查詢結果：

查詢操作全都轉到了 slave1.

可以看到, 在有 slave 故障后,MaxScale 會自動進行排除,不再向其轉發請求.

下面看下 slave2 再次上線后的情況.

登錄 slave2 的 MySQL 執行

mysql> start slave;

查看 MaxScale 服務器狀態

slave2 已經失效了.

查看日志信息

cat /tmp/maxscale1.log

尾部顯示：

2016-08-15 12:26:02 ? notice : Server changed state: slave2[172.17.0.4:3306]: lost_slave

提示 slave2 已經丟失.

查看客戶端查詢結果：

查詢操作全都轉到了 slave1.

可以看到, 在有 slave 故障后,MaxScale 會自動進行排除,不再向其轉發請求.

下面看下 slave2 再次上線后的情況.

登錄 slave2 的 MySQL 執行

mysql> start slave;

查看 MaxScale 服務器狀態

恢復了正常狀態,重新識別到了 slave2.

查看日志信息,顯示：

2016-08-15 12:32:36 ? notice : Server changed state: slave2[172.17.0.4:3306]: new_slave

查看客戶端查詢結果：

 

slave2 又可以正常接受查詢請求.

通過實驗可以看到,在部分 slave 發生故障時,MaxScale 可以自動識別出來,并移除路由列表,當故障恢復重新上線后,MaxScale 也能自動將其加入路由,過程透明.

2、全部 slave 故障的情況

分別登陸 slave1 和 slave2 的MySQL,執行停止復制的命令

mysql> stop slave;

查看 MaxScale 服務器狀態

發現各個服務器的角色都識別不出來了.

查看日志：

從日志中看到,MaxScale 發現2個slave 和 master 都丟了,然后報錯：沒有 master 了.

客戶端連接 MaxScale 時也失敗了.

說明從服務器全部失效后,會導致 master 也無法識別,使整個數據庫服務都失效了.

對于 slave 全部失效的情況,能否讓 master 還可用?這樣至少可以正常提供數據庫服務.

這需要修改 MaxScale 的配置,告訴 MaxScale 我們需要一個穩定的 master.

處理過程

先恢復兩個 slave,讓集群回到正常狀態,登陸兩個 slave 的MySQL.

mysql> start slave;

修改 MaxScale 配置文件,添加新的配置.

vi /etc/maxscale.cnf

找到 [MySQL Monitor] 部分,添加：

detect_stale_master=true

保存退出,然后重啟 MaxScale.

驗證

停掉兩臺 slave ,查看 MaxScale 服務器狀態.

可以看到,雖然 slave 都無法識別了,但 master 還在,并提示處于穩定狀態

客戶端執行請求：

客戶端可以連接 MaxScale,而且請求都轉到了 master 上,說明 slave 全部失效時,由 master 支撐了全部請求.

當恢復兩個 slave 后,整體狀態自動恢復正常,從客戶端執行請求時,又可以轉到 slave 上.

小結

通過測試發現,在部分 slave 故障情況下,對于客戶端是完全透明的,當全部 slave 故障時,經過簡單的配置,MaxScale 也可以很好地處理.

來源：性能與架構 訂閱號(ID：yogoup)作者：杜亦舒

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4443.html