记另一例mongo can not add session to cache
文章目录
线上环境又报:mongo can not add session to cache,有了之前的经验,这次排查和解决问题算是轻车熟路了。
日志!
直接登录到线上环境,查看mongo集群日志,发现此次问题和之前遇到的不太一样:
|
|
看这个样子,应该是内存中的activeSessionsCount
无法写入config.system.sessions
表中。
集群状态
运行命令查看当前集群节点状态:mongostat --discover --interactive --host 127.0.0.1:27010
果然,data_set1
的一个副节点挂掉了。
但是,主节点仍然在运行,正常情况下是可以写入数据的呀。先把这个挂掉的节点恢复再说!
writeConcern
接下来,就看一下mongo集群是怎样把activeSessionsCount
写入数据库的,继续查看日志,果然发现了端倪:
正常情况下,对system.sessions
表的写入操作有writeConcern: { w: "majority", wtimeout: 15000 }
这样的配置。
那结合我们线上环境集群节点副本集的配置 Primary-Secondary-Secondary (P-S-S)
模式,在挂掉一个节点之后,即使主节点仍然正常运行,w: "majority"
有这样写入配置的操作也是无法成功的。
mongodb官方文档中有描述:
Requests acknowledgment that write operations have propagated to the calculated majority of the data-bearing voting members (i.e. primary and secondaries with
members[n\].votes
greater than0
).For example, consider a replica set with 3 voting members, Primary-Secondary-Secondary (P-S-S). For this replica set, calculated majority is two, and the write must propagate to the primary and one secondary to acknowledge the write concern to the client.
也就是说,对于我们线上的副本集,必须保证主、副节点都正常运行,才可能达到 w: "majority"
的要求。
小结
此次问题说明一些问题:
- 当前我们对线上mongo集群的监控不足,副本集副节点挂掉较长一段(activeSessionsCount高达40多万)时间直到线上服务报错后才发现;
- 对mongodb的
writeConcern
和readConcern
研究不深入,对当前的集群部署模式研究不够。
后续需要继续完善对线上环境的监控和预警,深入研究mongodb本身。
文章作者 rgozi
上次更新 2021-08-10