前言
官方文档：https://docs.mongodb.com/manual/reference/program/mongos/#bin.mongos
mongos是mongodb shard的缩写，它是一个为应用层提供查询请求并决定数据在mongodb分片中位置的路由服务。从应用层的角度来看，mongos的行为和一个mongodb实例是没有区别的。
详细的配置参数，大概浏览一遍官方文档即可，需要用到的时候再去查就行了。
由于近期有不同用户先后遇到server-52654，做一些说明：
影响版本
所有使用mongodb 4.2.2+，并使用了分片的集群。
问题现象
从上次重启config节点，或者重新选举90或180天后，所有mongos会同时crash，并且无法重新启动。
问题原因
该问题是由于config节点无法正常刷新签名密钥导致。正常情况下存在2个密钥，一个正在使用的，将在90天内过期，一个即将使用的将在180天内过期。server-52654导致config无法正常刷新密钥，所以在现有密钥过期后mongos将崩溃。
修复版本
该问题将在4.2.12修复。4.2.12目前已发布。
规避办法
在90天内将primary节点stepdown一次即可避免该问题发生。如果想知道签名密钥的确切过期时间，可以连接到任意config节点，并执行以下脚本：
db.getsiblingdb("admin").system.keys.find().map(k => { return { _id: k._id, purpose: k.purpose, expiresat: new date(k.expiresat.gettime()*1000) }})
如果存在2个密钥（一个90天内过期，一个180天内过期），则暂时不用操作；如果只有1个密钥，则应该在90天内执行stepdown切换config主节点。
由于system.keys集合需要特殊权限方可访问，如果遇到权限问题，可能需要以下脚本来创建必要的角色（将admin更换为您使用的用户）：
use admin;
db.createrole({
role: "query_keys",
privileges: [
{ resource: { db: "admin", collection: "system.keys"}, actions: [ "find" ] },
],
roles: [ ]
});
db.grantrolestouser("admin", ["query_keys"])
config主节点重新选举后将产生新的过期时间，仍可通过上述脚本检查是否已刷新。
总结
到此这篇关于mongos崩溃后无法重启问题的解决方法的文章就介绍到这了,更多相关mongos崩溃后无法重启内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！