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放在一起。
<code> MaxScale 的下載地址：https://downloads.mariadb.com/files/MaxScale/<code>
根據自己的服務器選擇合適的安裝包。
以 centos 7 為例 安裝步驟如下：
<code>yum install libaio.x86_64 libaio-devel.x86_64 novacom-server.x86_64 libedit -y
rpm -ivh maxscale-1.4.3-1.centos.7.x86_64.rpm/<code>
（3）配置 MaxScale
在開始配置之前，需要在 master 中為 MaxScale 創建兩個用戶，用於監控模塊和路由模塊。
創建監控用戶
<code>mysql> create user scalemon@'%' identified by "111111";
mysql> grant replication slave, replication client on *.* to scalemon@'%';/<code>
創建路由用戶
<code>mysql> create user maxscale@'%' identified by "111111";
mysql> grant select on mysql.* to maxscale@'%';/<code>
用戶創建完成後，開始配置
<code>vi /etc/maxscale.cnf/<code>
找到 [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
執行啟動命令
<code>maxscale --config=/etc/maxscale.cnf/<code>
查看 MaxScale 的響應端口是否已經就緒
<code>netstat -ntelp/<code>
- 4006 是連接 MaxScale 時使用的端口
- 6603 是 MaxScale 管理器的端口
登錄 MaxScale 管理器，查看一下數據庫連接狀態，默認的用戶名和密碼是 admin/mariadb。
<code>maxadmin --user=admin --password=mariadb/<code>
MaxScale> list servers
可以看到，MaxScale 已經連接到了 master 和 slave。
（5）測試
先在 master 上創建一個測試用戶
<code>mysql> grant ALL PRIVILEGES on *.* to rtest@"%" Identified by "111111";/<code>
使用 Mysql 客戶端到連接 MaxScale
<code>mysql -h MaxScale所在的IP -P 4006 -u rtest -p111111/<code>
執行查看數據庫服務器名操作來獲取當前所在的數據庫：
開啟事務後，就自動路由到了 master，普通的查詢操作，是在 slave上
MaxScale 的配置完成了。
4 MaxScale 中 slave 故障處理
前面已經介紹了 MaxScale可以實現MySQL的讀寫分離和讀負載均衡，那麼當 slave 出現故障後，MaxScale 會如何處理呢？
例如有 3 臺數據庫服務器，一主二從的結構，數據庫名稱分別為 master, slave1, slave2。
現在我們實驗以下兩種情況：
（1）當一臺從服務器（ slave1 或者 slave2 ）出現故障後，查看 MaxScale 如何應對，及故障服務器重新上線後的情況
（2）當兩臺從服務器（ slave1 和 slave2 ）都出現故障後，查看 MaxScale 如何應對，及故障服務器重新上線後的情況
- 準備
為了深入查看 MaxScale 的狀態，需要把 MaxScale 的日誌打開：
修改配置文件
<code>vi /etc/maxscale.cnf/<code>
找到 [maxscale] 部分，這裡用來進行全局設置，在其中添加日誌。
- 配置
<code>log_info=1
logdir=/tmp//<code>
通過開啟 log_info 級別，可以看到 MaxScale 的路由日誌。
修改配置後，重啟 MaxScale 。
- 實驗過程
(1)單個 slave 故障的情況
初始狀態是一切正常。
停掉 slave2 的複製，登錄 slave2 的 mysql 執行。
<code>mysql> stop slave;/<code>
查看 MaxScale 服務器狀態
slave2 已經失效了。
查看日誌信息
<code>cat /tmp/maxscale1.log/<code>
尾部顯示：
<code>2016-08-15 12:26:02 notice : Server changed state: slave2[172.17.0.4:3306]: lost_slave/<code>
提示 slave2 已經丟失。
查看客戶端查詢結果：
查詢操作全都轉到了 slave1。
可以看到， 在有 slave 故障後，MaxScale 會自動進行排除，不再向其轉發請求。
下面看下 slave2 再次上線後的情況。
登錄 slave2 的 MySQL 執行
<code>mysql> start slave;/<code>
查看 MaxScale 服務器狀態
恢復了正常狀態，重新識別到了 slave2。
查看日誌信息，顯示：
<code>2016-08-15 12:32:36 notice : Server changed state: slave2[172.17.0.4:3306]: new_slave/<code>
查看客戶端查詢結果：
slave2 又可以正常接受查詢請求。
通過實驗可以看到，在部分 slave 發生故障時，MaxScale 可以自動識別出來，並移除路由列表，當故障恢復重新上線後，MaxScale 也能自動將其加入路由，過程透明。
(2)全部 slave 故障的情況
分別登陸 slave1 和 slave2 的MySQL，執行停止複製的命令
<code>mysql> stop slave;/<code>
查看 MaxScale 服務器狀態
發現各個服務器的角色都識別不出來了。
查看日誌：
從日誌中看到，MaxScale 發現2個slave 和 master 都丟了，然後報錯：沒有 master 了。
客戶端連接 MaxScale 時也失敗了。
說明從服務器全部失效後，會導致 master 也無法識別，使整個數據庫服務都失效了。
對於 slave 全部失效的情況，能否讓 master 還可用？這樣至少可以正常提供數據庫服務。
這需要修改 MaxScale 的配置，告訴 MaxScale 我們需要一個穩定的 master。
- 處理過程
先恢復兩個 slave，讓集群回到正常狀態，登陸兩個 slave 的MySQL。
<code>mysql> start slave;/<code>
修改 MaxScale 配置文件，添加新的配置。
<code>vi /etc/maxscale.cnf/<code>
找到 [MySQL Monitor] 部分，添加：
<code>detect_stale_master=true/<code>
保存退出，然後重啟 MaxScale。
- 驗證
停掉兩臺 slave ，查看 MaxScale 服務器狀態。
可以看到，雖然 slave 都無法識別了，但 master 還在，並提示處於穩定狀態
客戶端執行請求：
客戶端可以連接 MaxScale，而且請求都轉到了 master 上，說明 slave 全部失效時，由 master 支撐了全部請求。
當恢復兩個 slave 後，整體狀態自動恢復正常，從客戶端執行請求時，又可以轉到 slave 上。
小結
通過測試發現，在部分 slave 故障情況下，對於客戶端是完全透明的，當全部 slave 故障時，經過簡單的配置，MaxScale 也可以很好地處理。
閱讀更多 思想走了光v8v 的文章
