MySQL高可用方案MHA的一些總結和思考
MySQL高可用方案中MHA絕地是一個相當成熟的實現。對于數據的切換，其實MGR也能很好的完成，也就是說，數據層面的角色切換已經刻意很平滑的做好了，但是對于訪問IP的處理，還是有很大的空間，MHA提供了很多可選的空間來支持。
常見的組合方式有：
- MHA+VIP
- MHA+keepalive
- MHA+Zookeeper
當然MHA+VIP是一種很成熟和經典的方案了。
一般來說都有以下類似的架構方式，假設架構模式為一主兩從。對于應用訪問來說，提供的IP信息就依據綁定的VIP地址為準。VIP可以根據節點的數據狀態在不同節點間漂移，達到無縫切換的高可用。
MHA Manager是一個核心的調度器，有了它可以調度多套環境，當然MHA Manager自身也有單點，所以會考慮兩套MHA Manager節點來做冗余，實際上是做交叉互備，比如有100套環境，兩個MHA Manager節點，那就每個分50個節點，如果Manager節點出現故障，可以很順利的交接給Manager2來接管。
對于應用來說，就是統一通過VIP的方式來訪問。如果是在這個基礎上考慮中間件的方案，則數據訪問的策略會更加復雜一些。
對于這樣的一個基本方案，如果從多個維度來下鉆會發現有很多需要注意的地方，所以問題無處不在，可喜的是在MHA中幾乎都考慮到了。如果說得簡單點，主要有下面的幾個場景需要考慮：
- 數據庫主庫宕機
- 數據庫從庫宕機
- 重啟數據庫主庫
- 重啟數據庫從庫
- 從庫應用延遲
- 主從網絡延遲
- 主庫服務器宕機
- 從庫服務器宕機
- 一主多從切換優先級
- 網絡抖動的切換
- 手工主從切換
- 主節點IP調整
- 從節點IP調整
- 添加從節點
- 剔除從節點
- 網絡抖動的預防
- 半同步插件對于MHA的影響
- 自定義MHA腳本
所以上面的方案多多少少都需要考慮，如果用下面的圖來表示，就會大體有如下的一些紅色警告。所以各個層面都會有可能存在問題和異常，如何盡可能不影響業務，保持業務科持續訪問是重中之重。
舉一個比較糾結的問題，如果MHA Manager節點到數據庫主庫的網絡發生抖動，導致短時間不可訪問，我們是希望這個過程是不會做災難切換的，但是如果時間過長了，有2分鐘或者3分鐘都不可訪問，這個時候是切還是不切呢。這個時候信息還是相對較少的，如果我們加入應用服務器這個角色，如果應用服務器是可訪問的，那么就不切，如果應用訪問受到影響，那還是切吧。而且根據我們的測試，在MHA 0.56和0.57里面還是有一些差別。測試了多套環境，測試了多個特性，結合起來才會發現對于MHA的考慮會更加全面，而換句話說，了解了原委，才能更好的掌握MHA，也才能看到更多的問題，來嘗試定制它，使得它更加滿足于當前的業務需求。
