很久沒來更新博客，自感是一個只會搬磚的勞工，總搞些MySQL相關的資料庫實在無聊，且時不時遇到些不講道理的Dev吧，真的是心累至極，有種想回頭我也去乾開發的衝動，當個需求者有話語權要風得風，要雨得雨多帥。以上純屬個人小目標，萬一哪天實現了呢，豈不美滋滋，從此走上人生巔峰，頓覺做技術不再那麼枯燥了。 ...
很久沒來更新博客，自感是一個只會搬磚的勞工，總搞些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批量動網卡承擔的風險，加班加點排查問題，差點兒一覺醒來鍋從天降。總歸這些還是值得，讓我覺得高可用有時候並不能真的高可用，出現崩塌的時候又該何去何從，這是個問題。
