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放在一起。
根據自己的伺服器選擇合適的安裝包。
以 centos 7 為例 安裝步驟如下：
（3）配置 MaxScale
在開始配置之前，需要在 master 中為 MaxScale 建立兩個使用者，用於監控模組和路由模組。
建立監控使用者
建立路由使用者
使用者建立完成後，開始配置
找到 [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 的響應埠是否已經就緒
- 4006 是連線 MaxScale 時使用的埠
- 6603 是 MaxScale 管理器的埠
登入 MaxScale 管理器，檢視一下資料庫連線狀態，預設的使用者名稱和密碼是 admin/mariadb。
MaxScale> list servers
可以看到，MaxScale 已經連線到了 master 和 slave。
（5）測試
先在 master 上建立一個測試使用者
使用 Mysql 客戶端到連線 MaxScale
執行檢視資料庫伺服器名的操作來知道當前實際所在的資料庫：
開啟事務後，就自動路由到了 master，普通的查詢操作，是在 slave上
MaxScale 的配置完成了。
4、MaxScale 在 slave 有故障後的處理
前面已經介紹了 MaxScale可以實現MySQL的讀寫分離和讀負載均衡，那麼當 slave 出現故障後，MaxScale 會如何處理呢？
例如有 3 臺數據庫伺服器，一主二從的結構，資料庫名稱分別為 master, slave1, slave2。
現在我們實驗以下兩種情況：
（1）當一臺從伺服器（ slave1 或者 slave2 ）出現故障後，檢視 MaxScale 如何應對，及故障伺服器重新上線後的情況
（2）當兩臺從伺服器（ slave1 和 slave2 ）都出現故障後，檢視 MaxScale 如何應對，及故障伺服器重新上線後的情況
準備
為了更深入的檢視 MaxScale 的狀態，需要把 MaxScale 的日誌開啟：
修改配置檔案
找到 [maxscale] 部分，這裡用來進行全域性設定，在其中新增日誌。
配置
通過開啟 log_info 級別，可以看到 MaxScale 的路由日誌。
修改配置後，重啟 MaxScale 。
實驗過程
初始狀態是一切正常。
停掉 slave2 的複製，登入 slave2 的 mysql 執行。
檢視 MaxScale 伺服器狀態
slave2 已經失效了。
檢視日誌資訊
尾部顯示：
提示 slave2 已經丟失。
檢視客戶端查詢結果：
查詢操作全都轉到了 slave1。
可以看到， 在有 slave 故障後，MaxScale 會自動進行排除，不再向其轉發請求。
下面看下 slave2 再次上線後的情況。
登入 slave2 的 MySQL 執行
檢視 MaxScale 伺服器狀態
slave2 已經失效了。
檢視日誌資訊
尾部顯示：
提示 slave2 已經丟失。
檢視客戶端查詢結果：
查詢操作全都轉到了 slave1。
可以看到， 在有 slave 故障後，MaxScale 會自動進行排除，不再向其轉發請求。
下面看下 slave2 再次上線後的情況。
登入 slave2 的 MySQL 執行
檢視 MaxScale 伺服器狀態
恢復了正常狀態，重新識別到了 slave2。
檢視日誌資訊，顯示：
檢視客戶端查詢結果：
slave2 又可以正常接受查詢請求。
通過實驗可以看到，在部分 slave 發生故障時，MaxScale 可以自動識別出來，並移除路由列表，當故障恢復重新上線後，MaxScale 也能自動將其加入路由，過程透明。
分別登陸 slave1 和 slave2 的MySQL，執行停止複製的命令
檢視 MaxScale 伺服器狀態
發現各個伺服器的角色都識別不出來了。
檢視日誌：
從日誌中看到，MaxScale 發現2個slave 和 master 都丟了，然後報錯：沒有 master 了。
客戶端連線 MaxScale 時也失敗了。
說明從伺服器全部失效後，會導致 master 也無法識別，使整個資料庫服務都失效了。
對於 slave 全部失效的情況，能否讓 master 還可用？這樣至少可以正常提供資料庫服務。
這需要修改 MaxScale 的配置，告訴 MaxScale 我們需要一個穩定的 master。
處理過程
先恢復兩個 slave，讓叢集回到正常狀態，登陸兩個 slave 的MySQL。
修改 MaxScale 配置檔案，新增新的配置。
找到 [MySQL Monitor] 部分，新增：
儲存退出，然後重啟 MaxScale。
驗證
停掉兩臺 slave ，檢視 MaxScale 伺服器狀態。
可以看到，雖然 slave 都無法識別了，但 master 還在，並提示處於穩定狀態
客戶端執行請求：
客戶端可以連線 MaxScale，而且請求都轉到了 master 上，說明 slave 全部失效時，由 master 支撐了全部請求。
當恢復兩個 slave 後，整體狀態自動恢復正常，從客戶端執行請求時，又可以轉到 slave 上。
小結
通過測試發現，在部分 slave 故障情況下，對於客戶端是完全透明的，當全部 slave 故障時，經過簡單的配置，MaxScale 也可以很好地處理。