一 、引子

筆者剛開始進入公司的時候，主要是忙于分布式MySQL系統(tǒng)----MyShard的構(gòu)建，公司使用了大量的IDC機房，基于這種網(wǎng)絡(luò)特點，MyShard設(shè)計當初完全是為了是一套支持Multi-Master操作的高可用性的分布式數(shù)據(jù)庫，可以在多個機房中部署的業(yè)務上提供快速的寫操作，實現(xiàn)了分布式高可用存儲能力。

在業(yè)務增長期，MyShard解決了公司的很多大型的數(shù)據(jù)庫存儲業(yè)務，隨著公司業(yè)務逐漸穩(wěn)定下來，分布式存儲需求越來越少。而公司卻有大量的小業(yè)務以及不斷嘗試的各種新業(yè)務，需要越來越多的小數(shù)據(jù)量的數(shù)據(jù)庫存儲。

所以這時候發(fā)現(xiàn)，之前的工作方向一直集中在公司的10%不到的業(yè)務上，而公司的90%以上的存儲需求是MySQL的需求，目前有好上千套的MySQL在給不同的業(yè)務提供服務。而在當時，不管是MySQL的交付還是管理都比較原始，極端情況下，我們需要業(yè)務申請方自己提供服務器來部署MySQL，所以交付的周期也很長。而在高可用方面，都是需要業(yè)務方自己去處理主從切換等等問題，出現(xiàn)主數(shù)據(jù)庫故障的時候，往往需要業(yè)務方自己去修改配置文件，重啟進程，增加了服務的中斷時間。

二、為什么沒有采用開源的高可用方案

業(yè)界比較流行的MySQL的高可用方案主要有：MMM和MHA兩種，對這個方案的分析網(wǎng)上有很多，MHA是優(yōu)先選取的方案。

MHA的工作原理：

clipboard.png

當master出現(xiàn)故障時，通過對比slave之間I/O線程讀取master binlog的位置，選取最接近的slave做為latestslave。其它slave通過與latest slave對比生成差異中繼日志。在latest slave上應用從master保存的binlog，同時將latest slave提升為master。最后在其它slave上應用相應的差異中繼日志并開始從新的master開始復制。

在MHA實現(xiàn)Master故障切換過程中，MHA Node會試圖訪問故障的master（通過SSH），如果可以訪問（不是硬件故障，比如InnoDB數(shù)據(jù)文件損壞等），會保存二進制文件，以最大程度保證數(shù)據(jù)不丟失。MHA和半同步復制一起使用會大大降低數(shù)據(jù)丟失的危險。

MHA的優(yōu)點

MHA提供了一個通用的框架，我們可以自定義判斷和切換操作的步驟；而且，MHA的代碼開源，我們甚至可以進行二次開發(fā)，這都為高可用系統(tǒng)提供了很好的擴展 能力。

MHA的缺點

• 需要在各個節(jié)點間打通ssh信任，這對某些公司安全制度來說是個挑戰(zhàn)，因為如果某個節(jié)點被黑客攻破的話，其他節(jié)點也會跟著遭殃；
• 自帶提供的腳本還需要進一步補充完善，當然了，一般的使用還是夠用的。
• 雖然一個MHA Manger可以管理多個集群，但是沒有大規(guī)模集群的經(jīng)驗。
• 高可用依賴于vip的方案，譬如采用keepalive來達到vip的切換，但是keepalive會限制切換的主機必須在一個網(wǎng)段，對于跨機房不在一個網(wǎng)段的服務器來說，就無法支持了。在大規(guī)模為每個MySQL集群安排一個vip也是難以實現(xiàn)的。keepalive在一個網(wǎng)段內(nèi)，部署多套也會互相影響。

為什么不采用

我們公司的數(shù)據(jù)庫的特點：

• 數(shù)據(jù)庫多機房部署
• 數(shù)據(jù)庫集群規(guī)模上千
• 安全性考慮

三、四層代理----RDS項目

除了MMM和MHA之外，MySQL還可以采用代理來實現(xiàn)高可用，MySQL代理會比MHA方案更適合大規(guī)模的使用。

當時阿里和騰訊分別推出了rds和cdb。我們研究了騰訊的cdb方案，cdb是基于TGW也即是NAT的模式實現(xiàn)了4層代理模型，來達到MySQL的高可用以及負載均衡功能。

但是TGW方案有個比較大的問題就是需要修改MySQL協(xié)議，一旦修改MySQL協(xié)議，所有的客戶端（各種語言的驅(qū)動）都需要進行修改，這在推廣上是非常難的。

所以我們采用了一種折中的方案，啟動了RDS項目，主要用于提供MySQL內(nèi)部云服務，其中高可用方案如下圖所示，采用了iptables的NAT來實現(xiàn)MySQL的代理路由功能。

clipboard.png

4層代理層基本實現(xiàn)原理

業(yè)務方首先連接到代理服務器上，由于代理服務器上有NAT目標地址轉(zhuǎn)換規(guī)則，所以會轉(zhuǎn)到目標MySQL主機上，同時從MySQL主機回包到代理服務器后，由于有NAT源地址轉(zhuǎn)換規(guī)則，又會轉(zhuǎn)發(fā)回業(yè)務方，從而實現(xiàn)了代理功能。

下面舉例說明我們?nèi)绾螢橐粋€業(yè)務啟動RDS四層代理：
我們先準備好以下幾臺機器：

客戶端：172.26.14.16
代理 ：172.26.82.45 啟動業(yè)務代理端口20000
目標機器：172.26.82.7 部署MySQL 端口號為3306

在代理機器上設(shè)置規(guī)則：

1、打開forward
echo 1 > /proc/sys/net/ipv4/ip_forward

2、設(shè)置從客戶端請求的目標地址和原地址轉(zhuǎn)換規(guī)則
iptables -t nat -A PREROUTING -p tcp -s 172.26.14.16 --dport 3306 -j DNAT --to-destination 172.26.82.7:20000
iptables -t nat -A POSTROUTING -p tcp -d 172.26.82.7 --dport 20000 -j SNAT --to-source 172.26.82.45

3、設(shè)置好規(guī)則之后，就可以通過mysql來連接到代理的20000端口了。
mysql -utest -ptest -h172.26.82.45 -P20000
這時候，實際訪問的是172.26.82.7上3306端口的MySQL數(shù)據(jù)庫。

四、數(shù)據(jù)庫配置中心----代理層（7層代理）

筆者之前一直都在公司云存儲中心工作，由于種種原因，2015年年中調(diào)到了運維部的數(shù)據(jù)庫團隊，在這里才發(fā)現(xiàn)，rds項目其實只是在數(shù)據(jù)庫運維平臺中走出了很小的一步。為了提供全方位的數(shù)據(jù)庫云服務平臺，于是我們開始打造了全新的數(shù)據(jù)庫配置中心，同時提供MySQL、Redis、Mongodb等數(shù)據(jù)庫和緩存內(nèi)部云服務。

與此同時，之前在rds項目中實現(xiàn)的4層代理的缺點也越來越明顯：

• 1、只能使用MySQL主庫，M-M-S結(jié)構(gòu)是的MySQL資源極其浪費；
• 2、只能在單機房使用，跨機房訪問效率非常低；
• 3、運維功能太少，由于采用iptables，在代理機器上無法看到任何的連接信息，也無法捕獲任何業(yè)務訪問的指標，甚至于連接信息都無法獲取；

基于以上幾點原因，筆者決定開發(fā)基于7層應用層的MySQL代理層平臺，系統(tǒng)的具體架構(gòu)如下所示：

clipboard.png

由于代理層是自己實現(xiàn)的應用程序，所以筆者在代碼中很容易就實現(xiàn)以下幾個核心的功能：

1、授權(quán)認證模型；
2、SQL攔截；
3、負載均衡；
4、讀寫分離；
5、高可用；
6、大SQL隔離；

除了這些特性以外，基于我們公司的多機房特點，筆者給代理層添加了機房感知能力。在整個數(shù)據(jù)庫配置中心，每個代理層程序、每個MySQL實例都有機房屬性。有了機房屬性，代理層可以實現(xiàn)自動就近訪問MySQL的能力，從而提高了系統(tǒng)性能同時，簡化了業(yè)務程序的部署。

一個典型的業(yè)務部署例子如下：

clipboard.png

從上圖可以看出，應用程序永遠也不再需要考慮多機房高可用、負載均衡、讀寫分離的問題。而且由于代理層實現(xiàn)了高可用功能，一旦發(fā)現(xiàn)主寫MySQL故障，會自動把主讀切換為主寫，從而在秒級實現(xiàn)FAILOVER。

平臺級設(shè)計--多租戶模式

由于我們的代理層采用了平臺級的設(shè)計，上圖中的代理層可以連接多套業(yè)務（MySQL集群），新的業(yè)務只需要在zookeeper配置好，代理層就會自動感知，業(yè)務方馬上能夠在代理層上使用，而不需要為每個業(yè)務部署自己的獨立的代理層，從而極大的減少了運維成本。

除此以外采用代理層還為數(shù)據(jù)庫云服務平臺帶來不少好處：

• 業(yè)務方連接代理機器和相應的端口，底層MySQL主從切換可以對業(yè)務方透明；
• MySQL實例維護或者遷移可以對業(yè)務方透明（一鍵遷移）；
• MySQL業(yè)務擴容/縮容也對業(yè)務透明（一鍵擴縮容）；

代理層上線推廣到現(xiàn)在，已經(jīng)有好幾百套的MySQL集群跑在上面了，MySQL的高可用平臺成功落地。

五、后記

Mongodb相對于MySQL的一個很大的優(yōu)勢就是高可用性，MySQL的高可用方案很多，但是完美的方式不多，代理層是在我們公司成功實施的一套平臺，希望有機會能和業(yè)界一起探討和學習，實現(xiàn)更多完美的解決方案。

代理層雖然已經(jīng)在公司大規(guī)模使用，但是還有很多發(fā)展和改善的空間，隨著MySQL 5.6和MySQL 5.7的廣泛應用，GTID已經(jīng)非常成熟，由于公司內(nèi)部使用場景少，代理層的切換還沒有實現(xiàn)GTID模式的切換，所以下一階段，筆者會考慮實現(xiàn)基于GTID的高可用模式。