如何理解MongoDB高可用

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

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

關于如何理解MongoDB高可用問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。