Question

所以，我有一个非常奇怪的问题。昨天我的配置服务器副本集基本上停止了工作，我可以取回它的唯一方法是使用备份恢复它的内容并重新创建副本集。

到目前为止看起来很好，所有分片数据都是通过配置服务器上的sh.status（）显示的。同样在两个replicasets上我可以查询数据。

但是，在mongos实例中，我在尝试获取分片状态时会收到提示：

end.traineddata

我可以通过mongo从运行mongos的服务器连接到配置服务器。使用Mongo版本3.2.7，我不知道如何解决这个问题，因为我没有看到任何日志指向正确的方向......

配置服务器日志中唯一的一点是：

mongos> sh.status()
2016-09-05T09:49:15.645+0000 E QUERY    [thread1] Error: error: { "code" : 50, "ok" : 0, "errmsg" : "Operation timed out" } :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
DBCommandCursor@src/mongo/shell/query.js:689:1
DBQuery.prototype._exec@src/mongo/shell/query.js:118:28
DBQuery.prototype.hasNext@src/mongo/shell/query.js:276:5
DBCollection.prototype.findOne@src/mongo/shell/collection.js:289:10
printShardingStatus@src/mongo/shell/utils_sh.js:540:19
sh.status@src/mongo/shell/utils_sh.js:78:5
@(shell):1:1

Answer 1

您的操作很危险，您不应该只恢复配置服务器。这可能会导致群集元数据不一致。

当您使用replset配置服务器时，mongos将维护ConfigOpTime，这是配置服务器中最新提交的OpTime。这用作发送到配置服务器的请求参数（ReadConcern的AfterOpTime）的值，以便mongos不会读取可能稍后回滚的数据。 Mongos通过配置服务器或其他分片的响应获取此ConfigOpTime。

所以在你的情况下，你恢复你的配置服务器，从而引领新的选举，从而新的OpTime术语。但其他分片仍然缓存旧的配置服务器的OpTime。通常它有更高的期限。 Mongos使用这个更高的ConfigOpTime来要求配置服务器在此之后提供数据。它必须等到配置服务器达到这个时间（如果没有新的选举发生，那是不可能的）。

如果您确定群集元数据正常，请尝试重新启动所有mongodb分片，然后重新启动您的mongos。

配置服务器问题后的MongoDB超时

1 个答案: