搞会这个索引添加法，十亿级时延敏感集群想抖动都难( 三 )

本文插图

问题确认

通过前面的分析可以得出问题根因在于加索引引起从节点磁盘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构建索引核心流程及问题暴露过程
4.1 createIndex构建索引核心流程
业务链接代理通过createIndex命令添加background后台索引，其运行流程如下图所示：

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

主节点查询对应表数据，然后build构建索引。
索引数据构建执行完成后，返回客户端OK 。 (注意：主构建完成后就通知OK给客户端，实际上这时候从节点还没有开始构建索引)
生成createIndex对应oplog数据到oplog表
从节点获取到createIndex对应oplog操作，然后重放createIndex构建索引。

4.2 问题暴露流程
通过分析日志时间点和告警时间点，和业务确认，发现当业务第三个索引添加完成后(实际上只是主节点构建索引完成) ，开始触发时延告警阀值。总接时间序列如下：