返回ProxySQL系列文章：http://www.cnblogs.com/f-ck-need-u/p/7586194.html

?

ProxySQL有原生的集群功能，但是這個(gè)原生的集群功能還正在試驗(yàn)階段。本文會(huì)詳細(xì)介紹這個(gè)原生集群的實(shí)現(xiàn)細(xì)節(jié)。

1.ProxySQL部署在哪

在拓?fù)浣Y(jié)構(gòu)中，ProxySQL部署在應(yīng)用程序和MySQL集群的中間位置。應(yīng)用程序向ProxySQL發(fā)起SQL語句，ProxySQL分析收到的SQL語句，進(jìn)行匹配、重寫等操作，然后路由給后端MySQL集群中的某實(shí)例。

如圖：

上圖描述的是多個(gè)application共用一個(gè)ProxySQL實(shí)例，但需求總是多變的。例如有些app比較繁忙，我們想要將這些繁忙的app使用的ProxySQL分離出來，讓不同的application獨(dú)立使用一個(gè)ProxySQL甚至一個(gè)ProxySQL集群，讓那些不太繁忙的app共用一個(gè)ProxySQL。這種情形如下圖：

還可以為每個(gè)app都配置一個(gè)ProxySQL，如下圖。

這種配置的好處是明顯的，沒有單點(diǎn)故障，不需要額外的負(fù)載均衡，app+proxysql的節(jié)點(diǎn)可以輕松擴(kuò)展。但是，也有缺點(diǎn)，各ProxySQL之間無法共享查詢緩存。但無論如何，這是一種良好的配置方式。

此外，還可以使用多層結(jié)構(gòu)，對(duì)ProxySQL群進(jìn)行負(fù)載均衡。如下圖：

上圖幾個(gè)注意點(diǎn)：

負(fù)載軟件層，也可以使用ProxySQL對(duì)ProxySQL集群進(jìn)行負(fù)載均衡，因?yàn)镻roxySQL自身就是一個(gè)代理，而且是專門負(fù)責(zé)MySQL協(xié)議的代理。

在負(fù)載均衡層，要保證事務(wù)持久，不能讓一個(gè)事務(wù)內(nèi)的不同語句路由到不同的目標(biāo)上，也就是說負(fù)載的目標(biāo)是"有狀態(tài)"的。因此在使用lvs/haproxy時(shí)，必須想辦法保證事務(wù)持久性。通用性方法是，從多個(gè)ProxySQL節(jié)點(diǎn)中取出一個(gè)作為邏輯寫節(jié)點(diǎn)(可以有backup)，haproxy/lvs通過端口(也可以用戶名，但通常采用端口)代理的方式，強(qiáng)制將所有寫語句路由到這個(gè)固定的ProxySQL節(jié)點(diǎn)上。

而通過ProxySQL來代理ProxySQL集群，因?yàn)镻roxySQL內(nèi)部支持事務(wù)持久(在mysql_users表中字段transaction_persistent控制持久性)。

綜上分析，通過lvs/haproxy負(fù)載ProxySQL或者負(fù)載MySQL、Galera、組復(fù)制等，實(shí)非良策。而ProxySQL因其MySQL協(xié)議感知，完全能勝任這樣的負(fù)載工作。

?

無論如何，當(dāng)有多個(gè)ProxySQL實(shí)例構(gòu)成一個(gè)集群時(shí)，需要解決的問題是：如何保證ProxySQL的可用性、如何同步集群中各ProxySQL實(shí)例的配置。

目前ProxySQL原生集群功能還在研究當(dāng)中，在原生集群(ProxySQL Cluster)功能中，使用master、候選master和slave的概念，master和候選master負(fù)責(zé)投票，負(fù)責(zé)寫入、更改配置，并同步到集群中的其它節(jié)點(diǎn)。master故障后，還可以從候選Master中選舉一個(gè)新的master，如下兩圖。這些特性能保證ProxySQL集群的可用性、伸縮性。

但是現(xiàn)在，在試驗(yàn)階段步入穩(wěn)定可用階段之前，如何保證ProxySQL的可用性？只能借助第三方工具實(shí)現(xiàn)，例如：

• keepalived保證第一層次的代理高可用，缺點(diǎn)是可能會(huì)浪費(fèi)一臺(tái)機(jī)器(除非使用VRRP多實(shí)例的互為主從結(jié)構(gòu))；
  
• ZooKeeper，ZooKeeper實(shí)現(xiàn)的分布式鎖服務(wù)，可以人為進(jìn)行master選舉，從而協(xié)調(diào)整個(gè)ProxySQL集群。

這兩種方案的拓?fù)鋱D如下：

至于如何保證配置文件的同步性，其實(shí)這個(gè)不是大問題，只要通過管理工具，集群內(nèi)的所有ProxySQL實(shí)例都以完全相同的配置啟動(dòng)，并以批量管理工具(如ansible/salt)來管理各實(shí)例，那么配置同步問題就沒有多大問題。

但是需要注意，有些時(shí)候ProxySQL內(nèi)部會(huì)自動(dòng)執(zhí)行l(wèi)oad to runtime，例如某ProxySQL實(shí)例發(fā)現(xiàn)某個(gè)MySQL Server節(jié)點(diǎn)拖后腿(replication lag)，會(huì)臨時(shí)避開這個(gè)節(jié)點(diǎn)，這時(shí)會(huì)在內(nèi)部更改配置并load to runtime。這樣內(nèi)部自動(dòng)更改的配置如何同步到其它ProxySQL實(shí)例上去？其實(shí)這類內(nèi)部更改無需同步，因?yàn)樗蠵roxySQL實(shí)例都在監(jiān)控著后端，一個(gè)ProxySQL實(shí)例發(fā)現(xiàn)了問題，其它ProxySQL實(shí)例在極短的時(shí)間內(nèi)也一定會(huì)發(fā)現(xiàn)問題并自動(dòng)重新配置。

關(guān)于ProxySQL的集群拓?fù)?#xff0c;大概拋完磚了。經(jīng)過上面的初步分析，ProxySQL可以結(jié)合app部署，可以部署單層ProxySQL群，可以部署多層ProxySQL群，還可以相互結(jié)合起來部署。可見，ProxySQL的部署方式非常靈活，能實(shí)現(xiàn)的需求也很有彈性，具體如何實(shí)現(xiàn)，就看自己的了。

2.ProxySQL原生集群

關(guān)于ProxySQL的原生集群功能，我已將官方手冊(cè)部分進(jìn)行翻譯，ProxySQL Cluster。該手冊(cè)中已經(jīng)非常詳細(xì)地解釋了ProxySQL集群的實(shí)現(xiàn)細(xì)節(jié)，所以這里就不多做解釋了。

轉(zhuǎn)載于:https://www.cnblogs.com/f-ck-need-u/p/9362822.html

總結(jié)

以上是生活随笔為你收集整理的MySQL中间件之ProxySQL(13)：ProxySQL集群的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。