- 綠色版查看
- 綠色版查看
- 綠色版查看
- 綠色版查看
MySQL Router配置文件:
[DEFAULT]
logging_folder = /var/log/mysqlrouter
[logger]
level = INFO
[routing:failover]
bind_address = 10.166.224.50
bind_port = 7001
max_connections = 1024
mode = read-write
destinations = 10.166.224.33:3310,10.166.224.34:3310
[routing:balancing]
bind_address = 10.166.224.50
bind_port = 7002
connect_timeout = 3
max_connections = 1024
mode = read-only
destinations = 10.166.224.33:3310,10.166.224.34:3310
通過該配置文件啟動MySQL Router會監聽兩個端口10.166.224.50:7001和10.166.224.50:7002。10.166.224.50:7001是一個高可用的端口（mode=read-write），通過7001的端口訪問MySQL Router中間件會首先將請求發送到服務器10.166.224.33:3310，如果確定該服務器宕機，則會發送到服務器10.166.224.34:3310。10.166.224.50:7002是一個負載均衡的端口，每個都請求可以將通過roundrobin的方式發送到destiantions對應的MySQL服務器。通過MySQL Router用戶可以快速實現一個簡單的帶有讀寫分離的高可用集群。MySQL Router甚至可以鏈接MySQL Fabric的元數據庫，具體可查看MySQL Router的相關文檔。
測試體驗：
MySQL Router之前官方的中間件是MySQL Proxy，這么多年一直是alpha版本，堪稱業界奇跡。不過隨著MySQL Router的發布，官網其實已經無法直接下載MySQL Proxy了。但Inside君還是決定對MySQL Router和MySQL Proxy做一個簡單的性能測試。測試場景是全內存的SELECT操作，測試工具使用sysbench，測試環境是網易云主機。最終的測試結果如下圖所示：
測試使用16線程的select.lua腳本的測試，對比遠程客戶端直連MySQL，遠程客戶端連接MySQL Router，遠程客戶端連接到MySQL Proxy，后兩者需要再進行一個轉發才能連接到目的MySQL數據庫，因此性能肯定會比直連MySQL方式要差。從結果看MySQL Router比直連MySQL性能要差15%，QPS平均值接近20000。但是MySQL Proxy的測試結果QPS僅5700，簡直慘不忍睹。導致這樣結果最重要的原因是MySQL Proxy采用使用lua腳本語言，測試過程中CPU負載高達290%（4核CPU）。MySQL Proxy測試過程中CPU的使用率在50%左右，表現較為平穩。
看來MySQL Router用來做負載均衡是一個不錯的選擇，特別是用來做高可用架構下的只讀VIP，那么對比傳統的LVS性能又會是怎樣呢？接著Inside君又對比了MySQL Router和LVS的負載均衡性能測試對比，同樣是SELECT全內存測試，但是并發數提升至128個線程。測試結果如下所示:
可以發現在128個線程下單實例MySQL直連模式和MySQL Router中間件模式已經沒有太大的區別，QPS都在26000左右。當采用兩個MySQL實例實現只讀操作的負載均衡時，可以發現MySQL Router的QPS在48000左右，而LVS模式在52000左右，性能提升8%，更為重要的是LVS轉發服務器上基本沒有什么負載。
MySQL Router優點：
上手快，很容易配置
較為穩定，性能中沒有遇到什么問題
插件式的架構允許用戶進行額外功能的擴展
缺點：
僅支持簡單的負載均衡功能
高可用功能有待進一步測試
雖然支持Fabric元數據，但是不支持分庫分表（不得不說是一個遺憾）
白名單，SQL統計功能，防火墻功能缺失
需要gcc 4.8以上版本支持，老系統編譯比較麻煩些
您的評論需要經過審核才能顯示
有用
有用
有用