MYSQL 的中間件其實也很多，但實際上用的比較廣的（非分庫分表）的選擇點基本上會落到 PROXYSQL 和 MyRouter 兩個中間件中，1使用的人數多，2 豐富的文檔和至關多的案例mysql
實際上proxysql 能夠算是一個支持普遍的中間件，下面是其支持的產品線sql
本着沒有使用就沒有發言權的原則，如下內容僅僅是針對proxysql 中間件的使用的一些特色和優勢來闡述
數據庫
從官方網址 https://proxysql.com/ 下載最新的 proxysql rpm包後，直接yum -y install 包 安裝後。同時也要保證你的proxysql 主機安裝了MYSQL的客戶端。後端
啓動proxysql service proxysql start ， 對於proxysql 的配置基本上分爲如下幾個部分安全
1 MHA 方式服務器
1 登錄到PROXYSQL 的管理端 mysql -u admin -padmin -h 127.0.0.1 -P6032 --prompt='Admin> '
微信
2 進入後，實際上看到的databases 和咱們常規理解的是有區別的，PROXYSQL是架設在業界使用最普遍的sqllite 數據庫基礎上的產品，雖然支持MYSQL的客戶端，語法，但實際上後臺數據的存儲都是基於sqllite數據庫的。網絡
3 配置簡單，針對一個需求簡單的MHA，如何再也不使用VIP而是經過PROXYSQL來進行對應用透明的切換。架構
3.1 輸入MySQL的主從節點 mysql_servers性能
3.2 配置用戶 mysql_users
3.3 配置檢測切換方式 mysql_replication_hostgroups
作完這幾部，一個基於MHA 最簡單的PROXYSQL 方式的集羣就完成了。
優勢：去掉了VIP 的遷移的腳本，相關的穩定性大幅度提升，總體的架構的複雜性也下降了。
原理：
PROXYSQL 經過判斷默認 write組的連通性，咱們能夠作一下相關的實驗來證明在MHA的狀態下
1 到底proxysql 是怎麼來判斷數據庫到底在線仍是不在線
2 到底怎麼來判斷哪一個是讀庫，或者當庫變爲能夠寫的庫時，進行相關的訪問
答案就在下圖， proxysql 在 1- 2秒會經過查看當前服務器的read_only 來判斷當前的服務器是否應該在寫的組，而且在1 分鐘內會對所在的宿主服務器進行一個鏈接性的判斷。
咱們如下圖做爲一個例證，目前101的read_only 設置爲ON，而102 的 read_only 設置OFF ，也就是目前有兩臺MYSQL 主 102 從 101
咱們能夠將101 的 read_only 設置爲OFF 看看會出現什麼效果，能夠看到寫組中的 600組，多了101 這臺機器。
若是出現這樣的狀況就可能會引發數據不一致的狀況，因此要保證在同一個時間只能有一個寫庫，只能有一個機器的 read_only = off 其餘的集羣的機器的read_only必須是on.
上方是官方文檔，描述了
1 connect 鏈接的後端的成功和失敗的，信息將存儲在 mysql_server_connect_log 中
select * from mysql_server_connect_log;
2 查看proxysql 與 mysql之間的鏈接的狀況,經過 connect_success_time_us來看當前的網絡連通的狀況（能夠反映一部分）
下面是一些相關的關鍵的與監控有關的基本參數
1 mysql-monitor_enabled 是否打開監控
2 mysql-monitor_connect_timeout 鏈接超時的時間 600毫秒
3 mysql-monitor_ping_max_failures 嘗試鏈接失敗最大容忍數
4 mysql-monitor_ping_timeout 鏈接超時時間
判斷一個節點是否存活，以上面兩個方式來決定，因此若是你的網絡延遲，或者某方面不穩定，能夠調整某些參數已更適應與當前的設定。
5 mysql-monitor_read_only_max_timeout_count 設定當前read_only最大的超時的次數
6 mysql-monitor_replication_lag_interval 監控主從之間的數據傳輸差別，若是在設置了讀寫分離，這會讓讀寫分離中若是主從差別太大的狀況下，禁止將查詢發送到延時較大的物理庫中。
說到這裏，必定會有同窗問一個問題，我不怕主機宕機，或者MYSQL服務沒法提供服務，我怕的是
1 因爲網絡緣由，形成主庫從庫網絡沒法進行通訊，形成切庫，而後網絡又恢復了，此時就會出現一個問題，會有兩個機器目前存在 read_only = off 的狀態。那個人數據是否在繼續寫入的時候回不安全。
2 因爲主庫的緣由，OOM 切庫，而後主庫又起來了，此時也是 read_only = off > 1
咱們來看一下結果如何。
操做步驟
1 斷開primary 的網絡 102
2 等待切庫
3 切庫完畢 主庫 101
4 恢復primary 網絡 101 102 read_only = off
5 ？？？？？？ 寫入數據 到底會怎樣
圖1 的狀況是 5 鏈接到PROXYSQL 而後刪除了一個數據庫
結果若是是 101 和上圖狀況一致，則說明proxysql 解決了同時出現兩個read_only = off 的狀況
出現其餘狀況，則說明出現問題。
從上圖能夠看到，結果是正常的也是咱們想要的。
題目中的新想法是來自於proxysql 自己的一些監控和信息，若是將proxysql的一些監控信息利用好，則對於總體監控MHA 集羣有部分幫助，若是配合ZABBIX 則能夠繪製出一些有關的鏈接性能或其餘的一些圖形。
本文分享自微信公衆號 - AustinDatabases（AustinDatabases）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。