很久没来更新博客，自感是一个只会搬砖的劳工，总搞些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批量动网卡承担的风险，加班加点排查问题，差点儿一觉醒来锅从天降。总归这些还是值得，让我觉得高可用有时候并不能真的高可用，出现崩塌的时候又该何去何从，这是个问题。