如何理解MongoDB高可用，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領(lǐng)域包括：成都網(wǎng)站建設(shè)、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的固陽網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設(shè)合作伙伴！

服務器容災一直是云服務運維過程中無法避開的問題，我們常常會討論如何對出現(xiàn)故障的機器進行數(shù)據(jù)庫方面的恢復，卻很少考慮到在機器出現(xiàn)故障后，是用一套怎樣的處理流程將三節(jié)點副本集恢復如初的。
MongoDB采用的是什么方法，得以做到在有機器故障的情況下依舊能保證用戶業(yè)務的高可用？
對于MongoDB數(shù)據(jù)庫來說，MongoDB內(nèi)核就像汽車發(fā)動機，是整個數(shù)據(jù)庫運轉(zhuǎn)的核心部分，而管控就像拼裝汽車的過程。車子怎么跑，跑起來的效能如何，運轉(zhuǎn)是否安全，出現(xiàn)故障如何維修，諸如此類的任務都由管控部門負責處理。而保證用戶的業(yè)務能夠達到高可用，則是運維任務的重中之重：
那么，什么是高可用？
MongoDB服務采用三節(jié)點副本集架構(gòu)，三個數(shù)據(jù)節(jié)點位于不同的物理服務器上，分別自動同步數(shù)據(jù)。副本集提供三種角色，Primary節(jié)點（支持讀寫請求），Secondary節(jié)點（支持只讀請求），Hidden節(jié)點（提供備節(jié)點的角色，默認不支持訪問）。
而高可用，就是針對這一服務的容災切換和故障轉(zhuǎn)移的過程。這一過程有很高的自動化程度，通過Primary，Secondary和更多備用節(jié)點形成容災，當Primary節(jié)點出現(xiàn)故障，系統(tǒng)會自動選舉新的Primary節(jié)點。Secondary節(jié)點不可用，由備用節(jié)點接管并恢復服務，從多個方面保障服務的可用性。這便是MongoDB自身帶來的高可用。
高可用的最高境界就是：“容災故障關(guān)我何事？我只要業(yè)務ok”——從而做到將最穩(wěn)定的服務提供給用戶。對用戶來說，能夠看到的是Primary和Secondary兩個節(jié)點和暴露出的相關(guān)訪問鏈接。但在服務器上，同時還存在著另外一個Secondary節(jié)點處于Hidden狀態(tài)，這個節(jié)點通常用于數(shù)據(jù)備份以及性能優(yōu)化，在主節(jié)點出現(xiàn)故障時頂?shù)角胺?，切換成Secondary節(jié)點繼續(xù)承擔用戶的工作。
天有不測風云，服務器總會出現(xiàn)各式各樣難以排查的硬件故障，極端情況下甚至出現(xiàn)罷工：例如內(nèi)存ECC異常無法自動修復，硬盤IO異常讀寫失敗，RAID卡狀態(tài)有問題，電池斷電，網(wǎng)卡網(wǎng)絡滿載等。面對這些形形色色的故障類型，阿里對所有對外服務的服務器都提供了監(jiān)控，采用監(jiān)控系統(tǒng)對這些點進行實時采集，一旦發(fā)現(xiàn)問題便會及時的進行報警。
此外，諸如服務器到達質(zhì)保期的換新或者延保，系統(tǒng)升級OS，服務程序漏洞的修復，很多原因都可能導致服務器需要下線。
服務器下線了，用戶服務還要接著用，怎樣在拿掉機器進行線下升級的同時不影響用戶在跑的業(yè)務，這就需要交給MongoDB管控團隊去應對。
MongoDB用什么策略應對：
MongoDB高可用的實現(xiàn)流程分為以下三個部分：
故障檢測：使用多種檢測系統(tǒng)針對各種項目進行檢測，各個系統(tǒng)中存在聯(lián)動效應。
故障轉(zhuǎn)移：發(fā)生故障后怎樣將故障機器上的業(yè)務從該機器轉(zhuǎn)移出來。
主機下線：故障機器下線維修以及相應的后續(xù)過程。
故障檢測：
MongoDB服務集群里有大量不同型號的機器，例如D13、H43。每個服務器上都有與之對應的檢測程序，通過大量的Monitor進行監(jiān)控從而獲取信息：無論是內(nèi)部屬于阿里云自己的部分，還是在用戶的業(yè)務中由用戶實現(xiàn)的部分，都存在著與之對應的接口。阿里云會通過推送或自取的方式獲取實例并了解服務器的狀態(tài)，如果獲悉某臺機器存在下線的必要，資源管理器就會對這臺機器進行打標，確認異常后進入下一個階段。檢測和故障轉(zhuǎn)移兩個步驟之間并不是直來直去一步到位，其間實際上存在眾多細化的檢查過程。
故障轉(zhuǎn)移：
對阿里云提供的三節(jié)點副本集架構(gòu)而言，類似機器達到保修期，浪潮D13 RAID卡故障等許多情況下，都需要對任務的Primary節(jié)點機器進行下線維護。面對這些情況，資源管理器會對需要下線的機器進行打標，打標后的機器會進行實際的下線。而這些需要下線的機器往往還有業(yè)務正在運轉(zhuǎn)。為了保證業(yè)務不受影響，MongoDB會借用自身機制，把Secondary節(jié)點替換為Primary節(jié)點，從而使打標的節(jié)點變成Secondary狀態(tài)，之后會把打標節(jié)點從Secondary變成Hidden，即隱藏服務節(jié)點。原有的Hidden節(jié)點則作為容災節(jié)點被替換上去。
此時的Hidden（打標）節(jié)點上依舊存留著實例的數(shù)據(jù)，不能輕易下掉機器，這里會進入節(jié)點重搭的步驟——從資源池里額外再選一臺機器生產(chǎn)一個Hidden節(jié)點，等新的節(jié)點加入副本集后，并且完成三節(jié)點同步的情況下，被打標的機器才會被摘下，從而正式進入下線流程，這個過程往往需要一段時間才能完成。況且被打標的機器上面很可能存在多個實例，這臺機器上可能不只是某個實例的Primary節(jié)點，可能還存在其他實例的Secondary或者Hidden節(jié)點，但主體流程是類似的，打標機器上的所有節(jié)點最終都會替換成Hidden狀態(tài)，直到這臺機器達到?jīng)]有任何用戶訪問請求的效果。
為了不影響用戶對云服務的正常使用，整個切換過程都會在用戶提供的運維時間窗口里進行。
主機下線：
面對被下線的機器，系統(tǒng)并不會直接草率的將其置于主機資源池中，而是會有24H的滯留期，在滯留期內(nèi)，監(jiān)測系統(tǒng)會檢測滯留機器上是否還有其它訪問請求或IO讀寫操作。檢測結(jié)束，確定機器可以下線時才會將其放入主機資源池。資源池里的機器將進入另外一套系統(tǒng)進行后續(xù)操作，此時和MongoDB業(yè)務已經(jīng)關(guān)聯(lián)不大。會通過專用的IDCfree系統(tǒng)對機器進行恢復，待到確定機器沒問題后，我們才會重新將其放入資源池內(nèi)，通過自動上線系統(tǒng)重新加入MongoDB集群，這部分內(nèi)容由自動資源控制平臺來負責。接下來，我們就以實際的故障轉(zhuǎn)移業(yè)務場景為例子，闡釋關(guān)于高可用實現(xiàn)更具體的過程。
故障轉(zhuǎn)移業(yè)務場景：
一臺副本集出現(xiàn)問題：
故障機器打標確認進入轉(zhuǎn)移流程后，名為Robot的自動運維系統(tǒng)會先獲取機器上的實例信息，然后在用戶設(shè)定的可運維時間內(nèi)開始正式轉(zhuǎn)移（即使不在用戶設(shè)定的使用時間內(nèi)，依舊會通過短信對用戶進行告知）。在判定Role是Primary節(jié)點的情況下，先把Primary和Secondary節(jié)點進行置換，如果發(fā)現(xiàn)已經(jīng)是Secondary節(jié)點，那就進行Secondary和Hidden節(jié)點之間的的角色切換。這一步驟通過下發(fā)任務流的方式完成，后端完成置換的速度很快，對用戶的影響可以忽略不計。當確定故障機器全部變成Hidden節(jié)點時，開始觸發(fā)重搭Hidden流程，將新建的節(jié)點加入副本集。此時，有故障的節(jié)點已經(jīng)沒有任何實例存在，自動運維平臺會將這一空閑的問題機器置于可下線列表中，不再繼續(xù)進行即時的實例檢查。
故障遷移的時候存在一種獨特的說法：防風暴，波瀾不驚。

關(guān)于如何理解MongoDB高可用問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。