MySQL高可用方案中MHA絕地是一個(gè)相當(dāng)成熟的實(shí)現(xiàn)。對(duì)于數(shù)據(jù)的切換，其實(shí)MGR也能很好的完成，也就是說，數(shù)據(jù)層面的角色切換已經(jīng)刻意很平滑的做好了，但是對(duì)于訪問IP的處理，還是有很大的空間，MHA提供了很多可選的空間來支持。

　　常見的組合方式有：

　　MHA+VIP

　　MHA+keepalive

　　MHA+Zookeeper

　　當(dāng)然MHA+VIP是一種很成熟和經(jīng)典的方案了。

　　一般來說都有以下類似的架構(gòu)方式，假設(shè)架構(gòu)模式為一主兩從。對(duì)于應(yīng)用訪問來說，提供的IP信息就依據(jù)綁定的VIP地址為準(zhǔn)。VIP可以根據(jù)節(jié)點(diǎn)的數(shù)據(jù)狀態(tài)在不同節(jié)點(diǎn)間漂移，達(dá)到無縫切換的高可用。

　　MHA Manager是一個(gè)核心的調(diào)度器，有了它可以調(diào)度多套環(huán)境，當(dāng)然MHA Manager自身也有單點(diǎn)，所以會(huì)考慮兩套MHA Manager節(jié)點(diǎn)來做冗余，實(shí)際上是做交叉互備，比如有100套環(huán)境，兩個(gè)MHA Manager節(jié)點(diǎn)，那就每個(gè)分50個(gè)節(jié)點(diǎn)，如果Manager節(jié)點(diǎn)出現(xiàn)故障，可以很順利的交接給Manager2來接管。

　　對(duì)于應(yīng)用來說，就是統(tǒng)一通過VIP的方式來訪問。如果是在這個(gè)基礎(chǔ)上考慮中間件的方案，則數(shù)據(jù)訪問的策略會(huì)更加復(fù)雜一些。

　　對(duì)于這樣的一個(gè)基本方案，如果從多個(gè)維度來下鉆會(huì)發(fā)現(xiàn)有很多需要注意的地方，所以問題無處不在，可喜的是在MHA中幾乎都考慮到了。如果說得簡單點(diǎn)，主要有下面的幾個(gè)場(chǎng)景需要考慮：

　　數(shù)據(jù)庫主庫宕機(jī)

　　數(shù)據(jù)庫從庫宕機(jī)

　　重啟數(shù)據(jù)庫主庫

　　重啟數(shù)據(jù)庫從庫

　　從庫應(yīng)用延遲

　　主從網(wǎng)絡(luò)延遲

　　主庫服務(wù)器宕機(jī)

　　從庫服務(wù)器宕機(jī)

　　一主多從切換優(yōu)先級(jí)

　　網(wǎng)絡(luò)抖動(dòng)的切換

　　手工主從切換

　　主節(jié)點(diǎn)IP調(diào)整

　　從節(jié)點(diǎn)IP調(diào)整

　　添加從節(jié)點(diǎn)

　　剔除從節(jié)點(diǎn)

　　網(wǎng)絡(luò)抖動(dòng)的預(yù)防

　　半同步插件對(duì)于MHA的影響

　　自定義MHA腳本

　　所以上面的方案多多少少都需要考慮，如果用下面的圖來表示，就會(huì)大體有如下的一些紅色警告。所以各個(gè)層面都會(huì)有可能存在問題和異常，如何盡可能不影響業(yè)務(wù)，保持業(yè)務(wù)科持續(xù)訪問是重中之重。

　　舉一個(gè)比較糾結(jié)的問題，如果MHA Manager節(jié)點(diǎn)到數(shù)據(jù)庫主庫的網(wǎng)絡(luò)發(fā)生抖動(dòng)，導(dǎo)致短時(shí)間不可訪問，我們是希望這個(gè)過程是不會(huì)做災(zāi)難切換的，但是如果時(shí)間過長了，有2分鐘或者3分鐘都不可訪問，這個(gè)時(shí)候是切還是不切呢。這個(gè)時(shí)候信息還是相對(duì)較少的，如果我們加入應(yīng)用服務(wù)器這個(gè)角色，如果應(yīng)用服務(wù)器是可訪問的，那么就不切，如果應(yīng)用訪問受到影響，那還是切吧。而且根據(jù)我們的測(cè)試，在MHA 0.56和0.57里面還是有一些差別。測(cè)試了多套環(huán)境，測(cè)試了多個(gè)特性，結(jié)合起來才會(huì)發(fā)現(xiàn)對(duì)于MHA的考慮會(huì)更加全面，而換句話說，了解了原委，才能更好的掌握MHA，也才能看到更多的問題，來嘗試定制它，使得它更加滿足于當(dāng)前的業(yè)務(wù)需求。