如何理解MongoDB高可用

如何理解MongoDB高可用，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

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

關(guān)于如何理解MongoDB高可用問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。