MySQL高可用方案MHA怎么用

這篇文章主要為大家展示了“MySQL高可用方案MHA怎么用”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“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，也才能看到更多的問題，來嘗試定制它，使得它更加滿足于當前的業務需求。

以上是“MySQL高可用方案MHA怎么用”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！