返回 "ProxySQL系列文章：http://www.cnblogs.com/f ck need u/p/7586194.html" ProxySQL有原生的集群功能，但是這個原生的集群功能還正在試驗階段。本文會詳細介紹這個原生集群的實現細節。 1.ProxySQL部署在哪 在拓撲結 ...
返回ProxySQL系列文章：http://www.cnblogs.com/f-ck-need-u/p/7586194.html
ProxySQL有原生的集群功能，但是這個原生的集群功能還正在試驗階段。本文會詳細介紹這個原生集群的實現細節。
1.ProxySQL部署在哪
在拓撲結構中，ProxySQL部署在應用程式和MySQL集群的中間位置。應用程式向ProxySQL發起SQL語句，ProxySQL分析收到的SQL語句，進行匹配、重寫等操作，然後路由給後端MySQL集群中的某實例。
如圖：
上圖描述的是多個application共用一個ProxySQL實例，但需求總是多變的。例如有些app比較繁忙，我們想要將這些繁忙的app使用的ProxySQL分離出來，讓不同的application獨立使用一個ProxySQL甚至一個ProxySQL集群，讓那些不太繁忙的app共用一個ProxySQL。這種情形如下圖：
此外，還可以對ProxySQL集群進行負載均衡。如下圖：
註意上圖中的負載軟體層，也可以使用ProxySQL對ProxySQL集群進行負載均衡，因為ProxySQL自身就是一個代理，而且是專門負責MySQL協議的代理。
無論如何，當有多個ProxySQL實例構成一個集群時，需要解決的問題是：如何保證ProxySQL的可用性、如何同步集群中各ProxySQL實例的配置。
目前ProxySQL原生集群功能還在研究當中，在原生集群(ProxySQL Cluster)功能中，使用master、候選master和slave的概念，master和候選master負責投票，負責寫入、更改配置，並同步到集群中的其它節點。master故障後，還可以從候選Master中選舉一個新的master，如下兩圖。這些特性能保證ProxySQL集群的可用性、伸縮性。
但是現在，在試驗階段步入穩定可用階段之前，如何保證ProxySQL的可用性？只能藉助第三方工具實現，例如：
- keepalived保證第一層次的代理高可用，缺點是可能會浪費一臺機器(除非使用VRRP多實例的互為主從結構)；
- ZooKeeper，ZooKeeper實現的分散式鎖服務，可以人為進行master選舉，從而協調整個ProxySQL集群。
這兩種方案的拓撲圖如下：
至於如何保證配置文件的同步性，其實這個不是大問題，只要通過管理工具，集群內的所有ProxySQL實例都以完全相同的配置啟動，並以批量管理工具(如ansible/salt)來管理各實例，那麼配置同步問題就沒有多大問題。
但是需要註意，有些時候ProxySQL內部會自動執行load to runtime，例如某ProxySQL實例發現某個MySQL Server節點拖後腿(replication lag)，會臨時避開這個節點，這時會在內部更改配置並load to runtime。這樣內部自動更改的配置如何同步到其它ProxySQL實例上去？其實這類內部更改無需同步，因為所有ProxySQL實例都在監控著後端，一個ProxySQL實例發現了問題，其它ProxySQL實例在極短的時間內也一定會發現問題並自動重新配置。
關於ProxySQL的集群拓撲，大概拋完磚了，具體如何實現，就看自己的了。
2.ProxySQL原生集群
關於ProxySQL的原生集群功能，我已將官方手冊部分進行翻譯，ProxySQL Cluster。該手冊中已經非常詳細地解釋了ProxySQL集群的實現細節，所以這裡就不多做解釋了。
