线上某mongodb集群存储影响公司收入流水的核心数据，本文分享该集群为何多个索引串行后台会引起集群抖动，并且部分节点出现了连接数耗光等问题。同时通过本案例，给出时延敏感业务该最优方式添加索引，做到对业务最小化影响或者无影响。

索引对业务查询性能提升起着至关重要的作用，但是绝大部分mongodb程序员和DBA对时延敏感业务的索引添加方法是错误的。

本文主要完成一下几个目的：

某业务存储公司核心数据，集群异常会影响公司流水收入，该业务对时延非常敏感，稍有抖动就容易引起客户端超时异常，该业务场景如下：

该集群对应mongodb内核版本：3.6.13，某天业务自己通过mongodb管控平台串行方式添加几个索引(background后台添加)，一个索引添加执行完成返回后，业务开始下一个索引的添加。

添加第一个索引和第二个索引完成后，业务没告警，但是当业务添加完第三个索引后，开始收到部分查询时延超过阀值告警。

该集群部署架构如下：

该业务集群对应流量监控曲线如下：

如上图所示，该业务部署只有一个分片，该分片为一主四从结构5节点。分片1采用5节点的原因如下：

从上面的结构图可以看出，该集群只有一个分片，采用了分片模式架构，为何不选择复制集架构，这样还可以省掉mongos代理和config server的成本开销。采用分片模式主要基于如下因素考虑：

某天，突然告警中心打来电话，突然收到如下告警信息：

几乎四个从节点先后收到同样的告警，节点时延部分请求超过20ms，由于该业务是非常核心的影响业务营收的核心集群，非常紧张。但是，有一个很奇怪的现象，主节点访问时延正常，只有从节点时延抖动。

此外，还不停收到实例不可用异常告警，对应监控曲线如下：

收到告警后，发现业务有很多慢日志(时延敏感业务，慢日志打印阀值为20ms)，同时慢日志都走了最优索引。

于是通过mongo shell登陆节点后台，但是登陆不上，出现如下打印：

由于节点登陆不上，因此登陆到存储节点查看后台日志，日志中有大量的打印提示连接数耗光了，如下图：

从上面的现象可以看出链接耗光了，于是分析节点所在服务器系统监控，发现一个问题，磁盘IO非常高，如下：

由于从节点登陆不上，系统磁盘IO很高，因此怀疑有慢操作在运行，于是分析实例日志，发现如下现象：

通过前面的分析可以得出问题根因在于加索引引起从节点磁盘IO过高，最终引起业务查询时延上升抖动。

通过和业务沟通，业务这段时间确实通过我们的管控平台串行方式加了几个索引，磁盘IO过高由业务加索引引起，同时从节点同一时刻有多个索引添加。加索引过程首先需要读取表数据，然后通过数据构建索引，这个过程都会有多次IO操作。磁盘IO是公用的，服务器IO高会引起该服务器上所有的IO操作变慢，因此最终引起从节点读服务抖动。

到这里，我们已经确定问题是由于加索引引起，只有把索引干掉磁盘IO才会恢复正常，因此我们需要尽快干掉索引。然而，由于连接数已经耗光，无法链接从节点，所以我们不能做killop操作。

由于无法登陆后台做killop操作，于是直接kill进程，kill进程后启动，发现mongod还是在构建索引，如下：

重启后，还是需要构建索引，因为之前索引没有执行完成mongod进程就挂了，因此需要重建索引来保持与主节点状态一直。

不过，mongod为了解决类似问题，提供了一个noIndexBuildRetry参数来跳过实例加索引中途异常重启后重构索引的流程，该参数功能如下说明：

don't retry any index builds that were interrupted by shutdown    

noIndexBuildRetry放弃启动从节点mongod实例，业务很快恢复：

mongod -f /home/service/mongodb/conf/mongod_20001.conf --noIndexBuildRetry 

业务链接代理通过createIndex命令添加background后台索引，其运行流程如下图所示：

主节点接受到createIndex命令后的执行主要流程如下：

后台background加索引，确保所有主从索引构建完成后，才开始下一个索引的创建，避免出现本文所说的多个索引同时在从节点执行引起业务抖动。

无感知添加索引步骤如下：

    通过以上步骤，即可无感知方式完成一个从节点的索引添加，其他节点添加过程重复该操作过程即可。

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn