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

T1时刻第一个索引主节点构建完成，然后同步到两个从节点构建索引，也就是T1时刻两个从节点只有一个索引index1在运行。

T2时刻第二个索引主节点构建完成，然后从节点获取到这个索引执行，这时候由于从节点读流量大，因此构建索引比主节点慢，最终index1和index2都在两个从节点运行。此时，访问时延还没有触发时延告警阀值。

以此类推， T3时刻第三个索引添加完成，从节点通过oplog获取到第三个索引运行，由于此时index1、index2都还没有运行完成，因此两个从节点同时构建index1、index2和index3索引。三个索引的同时运行，进一步加重了磁盘IO负载和系统开销，业务访问时延进一步上升，最终造成部分查询时延超过20ms 。

总结如下图所示：

本文插图
五、疑问解答

为何background后台加索引会引起时延敏感集群抖动？

如上面分析，虽然业务是串行的方式一个索引添加成功后再添加下一个background后台索引，由于主从索引构建执行时间的长短不同，从节点通过拉取对应oplog重放，最终引起某一时刻开始三个索引在所有从节点同时运行，引起IO负载很高，最终触发业务访问时延告警。

为何前面两个索引添加过程没触发告警，第三个索引添加完成后才触发告警？

如上，从节点拉取Oplog获取到第三个索引执行的时候IO负载进一步增加，最终触发了20ms访问时延阀值。

为何只有从节点抖动，主节点时延一切正常？

主节点由于业务添加是一个索引后台添加完成后，才添加第二个索引。也就是主节点同一时刻只会有一个索引在执行， IO负载低，此外由于主节点写流量本身不高，读流量几乎都在从节点，索引加索引执行很快，并且几乎不会影响写流量时延。

为何连接数暴涨？

连接数暴涨实际上是加索引引起业务访问慢的结果，由于三个索引同时在从节点构建索引运行，造成从节点IO负载很高，最终造成业务访问变慢。
访问变慢后，会引起客户端链接池中的链接不够用，于是客户端会动态的增加链接池中的连接数来进行后端DB访问，最终造成了mongod服务端连接数到达配置上线出现无法链接的问题。

连接数耗光， mongo shell无法登陆查看节点内部状态信息，如何破局？

连接数耗光， mongo shell将无法连接节点，无法获取节点内部状态。可以对该功能做优化，对指定的客户端(默认127.0.0.1)设置白名单，取消max connections限制，这样我们即可通过节点本机登陆mongod后台获取内部状态信息。