你覺得的MongoDB副本集的高可用是真的高可用了嗎?

　　好久沒來更新博客，自感是一個只會搬磚的勞工，總搞些MySQL相關的數據庫實在無聊，且時不時遇到些不講道理的Dev吧，真的是心累至極，有種想回頭我也去幹開發的衝動，當個需求者有話語權要風得風，要雨得雨多帥。以上純屬我的小目標，萬一哪天實現了呢，豈不美滋滋，今後走上人生巔峯，頓覺作技術再也不那麼枯燥了。

       最近接觸了另外一種當下比較流行的MongoDB數據庫，不覺又get了一項新技能，能夠與人「侃侃而談」了。談點兒我的感覺吧，MongoDB是一個很是不錯的文檔型數據庫，一些以爲MySQL數據庫存儲json文檔維護成本高能夠放到MongoDB；不借助其餘第三方工具實現高可用和分片功能，這相似與MySQL的MHA、MMM，實現了高可用的故障切換，保障了服務可用；另外一大特性分片能夠實現數據的分部均衡，大數據量的時候經過路由實現了服務器的負載均衡，這個功能實現了網易前段時間開源的Cetus的功能，但自帶的工具兼容性會好一些，維護起來也方便。

        我剛接觸MongoDB也以爲這種數據庫開發者很仁義，不只提供了一個新型的場景數據庫，還想到了服務高可用，甚至延伸到了另外一個階段數據量上來了，服務器單集羣或者機器性能不足的問題。但是真當遇到了，你真的會覺得高可用就能高可用了嗎？若是你告訴我MongoDB自帶的投票機制能夠，那待我分享下最近的兩次慘痛經歷，你還會相信絕對嗎？

        MongoDB的OOM問題：MongoDB是最近才交付給DB運維的數據庫，以前一直由op進行維護，能夠講公司以及集團內部熟悉MongoDB的人幾乎沒有，so配置文件很粗糙，對於內存沒有作限制。終於有一天一個複用的MongoDB集羣不堪忍受爆發了，大體是datavisor的任務多個進程，單進程佔用了12G內存，MongoDB也沒有作內存限制，半夜3點、6點分別出現OOM宕機事故。可氣的是半夜宕機呀，誰能忍受。宕了一臺也就算了，集羣另外一臺也由於一樣的問題GG了，而後服務不可用。告警出現disaster級別，領導各類指導，一頓忙活（限制MongoDB內存，讓出資源給datavisor使用）終於解決了這個連續兩天集羣宕機的故障。（MongoDB是一種較吃內存的數據，按照官方文檔的意思大概是物理內存的一半減小一個G就是MongoDB佔用的內存，可是呢通過個人test發現事實並非這樣）。

        不要問我爲何MongoDB的集羣OOM問題能查兩天，出現三次集羣宕機的低級事故，下面談下當今最火的數據倉庫給各位DBA帶來的暴擊傷害。

       MongoDB的網絡限速處理：若是你的公司剛好有數據倉庫部門，業務數據量大或者抽取策略不合理，那麼我以爲你有必要考慮下MongoDB的網絡限速，不然容易將核心業務交換機流量打滿，單個抽取的服務器網卡流量打滿，被抽取的MongoDB機器出現故障切換後二次沒得切換出現集羣崩塌的局面。

        以上兩點淺嘗輒止，簡短分析下，不詳細贅述了，說多了又該講講那些我anscript批量動網卡承擔的風險，加班加點排查問題，差點兒一覺醒來鍋從天降。總歸這些仍是值得，讓我以爲高可用有時候並不能真的高可用，出現崩塌的時候又該何去何從，這是個問題。