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中幾乎都考慮到了。如果說得簡(jiǎn)單點(diǎn)，主要有下面的幾個(gè)場(chǎng)景需要考慮：

1. 數(shù)據(jù)庫主庫宕機(jī)
2. 數(shù)據(jù)庫從庫宕機(jī)
3. 重啟數(shù)據(jù)庫主庫
4. 重啟數(shù)據(jù)庫從庫
5. 從庫應(yīng)用延遲
6. 主從網(wǎng)絡(luò)延遲
7. 主庫服務(wù)器宕機(jī)
8. 從庫服務(wù)器宕機(jī)
9. 一主多從切換優(yōu)先級(jí)
10. 網(wǎng)絡(luò)抖動(dòng)的切換
11. 手工主從切換
12. 主節(jié)點(diǎn)IP調(diào)整
13. 從節(jié)點(diǎn)IP調(diào)整
14. 添加從節(jié)點(diǎn)
15. 剔除從節(jié)點(diǎn)
16. 網(wǎng)絡(luò)抖動(dòng)的預(yù)防
17. 半同步插件對(duì)于MHA的影響
18. 自定義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í)間過長(zhǎng)了，有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ù)需求。