MongoS 分片元数据管理器请求实例失败被手动重置

MongoS sharding metadata manager failed asking for instance is manually reset

我的 MongoS 服务器没有启动,它们在日志中发送此错误。

SHARDING [Balancer] caught exception while doing balance: Server's sharding metadata manager failed to initialize and will remain in this state until the instance is manually reset :: caused by :: HostNotFound: unable to resolve DNS for host confserv_1.xyz.com

2016-05-02T17:57:06.612+0530 I SHARDING [Balancer] about to log metadata event into actionlog: { _id: "DB2255-2016-05-02T17:57:06.611+0530-5727479aa1051c5fb04fcc49", server: "mongoS1", clientAddr: "", time: new Date(1462192026611), what: "balancer.round", ns: "", details: { executionTimeMillis: 35, errorOccured: true, errmsg: "Server's sharding metadata manager failed to initialize and will remain in this state until the instance is manually reset :: caused by :: HostNotFoun..." } }  

当我使用主机名连接配置服务器时,它工作正常。
我尝试重新启动 MongoS 服务器,但它没有启动。

我检查了 Mongo 代码,发现了
中提到的这个错误 https://github.com/mongodb/mongo/blob/master/src/mongo/db/s/sharding_state.cpp

/ TODO: remove after v3.4.
// This is for backwards compatibility with old style initialization through metadata
// commands/setShardVersion. As well as all assignments to _initializationStatus and
// _setInitializationState_inlock in this method.
if (_getInitializationState() == InitializationState::kInitializing) {
    auto waitStatus = _waitForInitialization_inlock(deadline, lk);
    if (!waitStatus.isOK()) {
        return waitStatus;
    }
}

if (_getInitializationState() == InitializationState::kError) {
    return {ErrorCodes::ManualInterventionRequired,
            str::stream() << "Server's sharding metadata manager failed to initialize and will "
                             "remain in this state until the instance is manually reset"
                          << causedBy(_initializationStatus)};
}  

但它没有提到任何需要手动干预的内容。 当前 Mongo 版本是 3.2.6

我只是 运行 在尝试加强安全配置时遇到这个问题。与您的情况一样,我能够从所有 mongos 实例连接到配置服务器。

在我的案例中,我还测试了一个副本集成员位于不同数据中心的案例,我只是在 steppingDown 一些初选后才遇到问题。

最后我注意到,问题不是错误消息假装的那样,而是发生在一个数据中心的某些主服务器上,这些主服务器无法路由回配置服务器。解决路由问题后(/etc/hosts 最终),mongo 侧不再出现问题。