你觉得的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批量动网卡承担的风险，加班加点排查问题，差点儿一觉醒来锅从天降。总归这些仍是值得，让我以为高可用有时候并不能真的高可用，出现崩塌的时候又该何去何从，这是个问题。