新聞中心
這篇文章主要為大家展示了“MySQL高可用方案MHA怎么用”,內(nèi)容簡而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領(lǐng)大家一起研究并學習一下“MySQL高可用方案MHA怎么用”這篇文章吧。
MySQL高可用方案中MHA絕地是一個相當成熟的實現(xiàn)。對于數(shù)據(jù)的切換,其實MGR也能很好的完成,也就是說,數(shù)據(jù)層面的角色切換已經(jīng)刻意很平滑的做好了,但是對于訪問IP的處理,還是有很大的空間,MHA提供了很多可選的空間來支持。
常見的組合方式有:
MHA+VIP
MHA+keepalive
MHA+Zookeeper
當然MHA+VIP是一種很成熟和經(jīng)典的方案了。
一般來說都有以下類似的架構(gòu)方式,假設(shè)架構(gòu)模式為一主兩從。對于應用訪問來說,提供的IP信息就依據(jù)綁定的VIP地址為準。VIP可以根據(jù)節(jié)點的數(shù)據(jù)狀態(tài)在不同節(jié)點間漂移,達到無縫切換的高可用。
MHA Manager是一個核心的調(diào)度器,有了它可以調(diào)度多套環(huán)境,當然MHA Manager自身也有單點,所以會考慮兩套MHA Manager節(jié)點來做冗余,實際上是做交叉互備,比如有100套環(huán)境,兩個MHA Manager節(jié)點,那就每個分50個節(jié)點,如果Manager節(jié)點出現(xiàn)故障,可以很順利的交接給Manager2來接管。
對于應用來說,就是統(tǒng)一通過VIP的方式來訪問。如果是在這個基礎(chǔ)上考慮中間件的方案,則數(shù)據(jù)訪問的策略會更加復雜一些。
對于這樣的一個基本方案,如果從多個維度來下鉆會發(fā)現(xiàn)有很多需要注意的地方,所以問題無處不在,可喜的是在MHA中幾乎都考慮到了。如果說得簡單點,主要有下面的幾個場景需要考慮:
數(shù)據(jù)庫主庫宕機
數(shù)據(jù)庫從庫宕機
重啟數(shù)據(jù)庫主庫
重啟數(shù)據(jù)庫從庫
從庫應用延遲
主從網(wǎng)絡延遲
主庫服務器宕機
從庫服務器宕機
一主多從切換優(yōu)先級
網(wǎng)絡抖動的切換
手工主從切換
主節(jié)點IP調(diào)整
從節(jié)點IP調(diào)整
添加從節(jié)點
剔除從節(jié)點
網(wǎng)絡抖動的預防
半同步插件對于MHA的影響
自定義MHA腳本
所以上面的方案多多少少都需要考慮,如果用下面的圖來表示,就會大體有如下的一些紅色警告。所以各個層面都會有可能存在問題和異常,如何盡可能不影響業(yè)務,保持業(yè)務科持續(xù)訪問是重中之重。
舉一個比較糾結(jié)的問題,如果MHA Manager節(jié)點到數(shù)據(jù)庫主庫的網(wǎng)絡發(fā)生抖動,導致短時間不可訪問,我們是希望這個過程是不會做災難切換的,但是如果時間過長了,有2分鐘或者3分鐘都不可訪問,這個時候是切還是不切呢。這個時候信息還是相對較少的,如果我們加入應用服務器這個角色,如果應用服務器是可訪問的,那么就不切,如果應用訪問受到影響,那還是切吧。而且根據(jù)我們的測試,在MHA 0.56和0.57里面還是有一些差別。測試了多套環(huán)境,測試了多個特性,結(jié)合起來才會發(fā)現(xiàn)對于MHA的考慮會更加全面,而換句話說,了解了原委,才能更好的掌握MHA,也才能看到更多的問題,來嘗試定制它,使得它更加滿足于當前的業(yè)務需求。
以上是“MySQL高可用方案MHA怎么用”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對大家有所幫助,如果還想學習更多知識,歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道!
網(wǎng)站欄目:MySQL高可用方案MHA怎么用-創(chuàng)新互聯(lián)
標題網(wǎng)址:http://fisionsoft.com.cn/article/diehoo.html