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中幾乎都考慮到了。如果說得簡單點，主要有下面的幾個場景需要考慮：

1. 資料庫主庫當機

2. 資料庫從庫當機

3. 重啟資料庫主庫

4. 重啟資料庫從庫

5. 從庫應用延遲

6. 主從網路延遲

7. 主庫伺服器當機

8. 從庫伺服器當機

9. 一主多從切換優先順序

10. 網路抖動的切換

11. 手工主從切換

12. 主節點IP調整

13. 從節點IP調整

14. 新增從節點

15. 剔除從節點

16. 網路抖動的預防

17. 半同步外掛對於MHA的影響

18. 自定義MHA指令碼

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

舉一個比較糾結的問題，如果MHA Manager節點到資料庫主庫的網路發生抖動，導致短時間不可訪問，我們是希望這個過程是不會做災難切換的，但是如果時間過長了，有2分鐘或者3分鐘都不可訪問，這個時候是切還是不切呢。這個時候資訊還是相對較少的，如果我們加入應用伺服器這個角色，如果應用伺服器是可訪問的，那麼就不切，如果應用訪問受到影響，那還是切吧。而且根據我們的測試，在MHA 0.56和0.57裡面還是有一些差別。測試了多套環境，測試了多個特性，結合起來才會發現對於MHA的考慮會更加全面，而換句話說，瞭解了原委，才能更好的掌握MHA，也才能看到更多的問題，來嘗試定製它，使得它更加滿足於當前的業務需求。