线上某MongoDB集群存储影响公司收入流水的核心数据,本文分享该集群为何多个索引串行后台会引起集群抖动,并且部分节点出现了连接数耗光等问题。同时通过本案例,给出时延敏感业务该最优方式添加索引,做到对业务最小化影响或者无影响。
索引对业务查询性能提升起着至关重要的作用,但是绝大部分MongoDB程序员和DBA对时延敏感业务的索引添加方法是错误的。
本文主要完成一下几个目的:
- 为何backgroud后台加索引会引起时延敏感集群抖动?
- 为何前面两个索引添加过程没触发告警,第三个索引添加完成后才触发告警?
- 为何只有从节点抖动,主节点时延一切正常?
- 为何连接数暴涨?
- 连接数耗光,mongo shell无法登陆查看节点内部状态信息,如何破局?
- 时延敏感型业务如何做到业务无感知索引添加?
1. 业务背景
某业务存储公司核心数据,集群异常会影响公司流水收入,该业务对时延非常敏感,稍有抖动就容易引起客户端超时异常,该业务场景如下:
- 数据量很小,10亿级
- 核心业务
- 时延敏感
- 分片模式,单个分片
- 读写分离
- 读多写少
- 峰值流量8-10W/s
该集群对应MongoDB内核版本:3.6.13,某天业务自己通过MongoDB管控平台串行方式添加几个索引(backgroud后台添加),一个索引添加执行完成返回后,业务开始下一个索引的添加。
添加第一个索引和第二个索引完成后,业务没告警,但是当业务添加完第三个索引后,开始收到部分查询时延超过阀值告警。
2. 集群架构
2.1 集群部署架构
该集群部署架构如下:
该业务集群对应流量监控曲线如下:
如上图所示,该业务部署只有一个分片,该分片为一主四从结构5节点。分片1采用5节点的原因如下:
①核心业务,5副本方式部署,可以容忍两个节点估值
②时延敏感,由于业务优先读从节点,因此可以通过增加分片从节点的方式提升业务的QPS。
2.2 一个分片为何要选择分片模式?
一个分片为何要选择分片模式?复制集不是可以满足要求吗?