这场MongDB事故暴露的潜在危机，你是否也正在忽视？

一、MongoDB特性

MongoDB是一个可扩展的高性能基于文档的NoSQL数据库，具备但不限于以下特性：

无数据结构限制和高性能

•  MongoDB以文档结构的存储方式，能够更便捷的获取数据；
•  MongoDB没有表结构的概念，每条记录可以有完全不同的结构，业务开发方便快捷，而SQL数据库需要事先定义表结构再使用；
•  在简单的业务结构下，其性能高于MySQL，如：MongoDB不指定_id插入>MySQL不指定主键插入>MySQL指定主键插入。

丰富的支持

•  Redis的key-value（只能按key查询，灵活性和易用性不足），而MongoDB支持单键索引、多键索引、数组索引、全文索引、地理位置索引、过期索引等；
•  MongoDB执行支持范围查询，正则表达式查询，对子文档属性的查询等，是最像SQL数据库的NoSQL数据库；
•  内置GridFS，支持大容量的存储。

方便的冗余与扩展

•  MongoDB的单机可靠性较差，但其复制集可保证数据安全；
•  分片扩展可处理大数据量的业务，其副本、分片伸缩扩展方便，维护简单。

良好的支持

•  官方拥有完善的文档；
•  齐全的驱动支持：官方提供了多数流行编程语言的驱动支持；
•  拥有诸多第三方社区论坛。

二、MongoDB故障经历

基于MongoDB的优异性能，在我司也越来越多的使用。随着业务变更，负载增加，一些问题也逐渐暴露出来，在我司内部最近就遭遇多起MongoDB故障，下面简单介绍其中一个：

业务背景

该套系统为内部主机监控系统，包括IO、CPU、内存、文件系统以及网络数据等，根据其监控项目本身特性，采样频率几秒到10分钟不等，因接入监控的主机数量较多，每日数据量较大。

该业务初始使用了3分片的cluster，分片规划由业务侧同事规划实施。

故障过程

业务侧反馈特定某些时段业务无法连接到MongoDB，往往几分钟后自动恢复了正常，且最近业务响应比以前明显减慢。

故障分析

接到反馈后，检查MongoDB日志，发现阶段性出现连接用尽的告警，猜测可能是业务最近有过调整。后经业务同事确认，最近确认新接入了一批主机到该监控系统。

•  MongoDB连接数、maxConns参数和os参数配置的单个进程能打开的最大文件描述符数总量的80%决定的，取两个之间的最小值；
•  maxConns配置为3000，系统open files参数为1024；
•  MongoDB最大连接数为(open files value) * 80%=1024* 80%=819。

理论值和故障时情况匹配，判定造成业务间断性无法连接的原因是参数设置不合理。

间断性出现和业务模式有关系，前面提到业务不同指标间隔几秒到十分钟采样，采样入库峰值时部分业务失败。

临时处置

得益于MongoDB的副本集方便调整的特点，滚动修改了各个节点参数(调整open files value到64000)，并重启MongoDB服务。

深入分析

此次故障原因很简单，但这引发了我们一些反思：

•  我们的使用方式真的正确吗？
•  我们的配置真的合理吗？
•  我们关注过性能吗？
•  我们的设计真的合理么？

带着这样的问题，我们重新审视分析了该系统的使用情况。不查不知道，一查下一跳，真的检查出诸多问题：

•  操作系统所有参数均为默认参数；
•  MongoDB除必要参数外均为默认配置；
•  MongoDB集合未分片或分片不合理，不能发挥MongoDB分片的优势，所有负载都集中在一个分片。

调整优化

针对存在的问题做了以下几方面的调整：

调整系统参数

•  /etc/security/limits.conf 

mongo soft nofile 64000  
mongo hard nofile 64000  
mongo soft nproc 32000  
mongo hard nproc 32000 

•  /etc/sysctl.conf 

fs.file-max=98000  
kernel.pid_max=64000  
kernel.threads-max=64000  
vm.max_map_count=128000 

此外禁用了numa，Transparent HugePages及修改了磁盘调度策略：

开启MongoDB Profile

profile = 1  
slowms = 200 

结合业务重新设置集合片键

重新设计分片是本次调整的重点，那么为什么说当前系统的分片不合理，分片的依据是什么呢？这里先说一下我们评估的依据：

好的片键

•  将插入数据均匀分布到各个分片上；
•  保证CRUD操作能够利用局部性；
•  有足够的粒度进行块拆分；
•  片键上必须有索引，最好选择业务会用到的索引字段分片。

不好的片键

•  小基数片键：随着数据的增加，一个chunk逐渐变大，无法继续分裂，只能添加硬盘来保证足够的空间存储数据；
•  避免升序片键：范围分片的范围为正负无穷，如果使用升序片键(包含object_id及时间，自增主键等)，那么最近的数据始终存储在一个分片，不能充分利用到分片带来的好处；
•  随机片键：随着数据的增大，由于其随机性，分片间的数据平衡可能需要加载大量的块到内存和引发大量IO，导致性能降低。

当前数据库内仅有少数集合进行了分片，并且片键均为时间类型，造成负载集中在其中一个分片上。我们希望能找到一种既能保证足够的粒度，不会造成巨型chunk，也能控制分片粒度，不会降低效率。

按照上述原则，我们搭建了测试环境，与业务同事共同讨论并进行了多次测试，尝试了不同的分片组合及分片方式，对比了不同分片下的业务性能，我们总结出如下规则：

{Locality: 1,search : 1}：第一个字段控制局部的数据，第二个字段为常用的搜索字段；第一个字段为粗粒度字段，第二个字段为细粒度字段。

结果对比

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!