rs.stepDown（）之后mongodb java驱动程序找不到master答案

【问题标题】：mongodb java driver not finding master after rs.stepDown()rs.stepDown（）之后mongodb java驱动程序找不到master
【发布时间】：2013-12-18 04:54:10
【问题描述】：

Grails 2.2.1 MongoDB GORM 插件 1.2

当使用副本集运行时，我发现降低主节点会导致 java 驱动程序中出现以下无限重复错误。

2013-09-09 16:00:19,655 [SimpleAsyncTaskExecutor-1] ERROR grails.app.services.plover.UserStreamAnalyzerService  - Exception while handling status update event: org.springframework.data.mongodb.UncategorizedMongoDbException: not talking to master and retries used up; nested exception is com.mongodb.MongoException: not talking to master and retries used up

... 引起：org.springframework.data.mongodb.UncategorizedMongoDbException：不与master交谈并且重试用完；嵌套异常是 com.mongodb.MongoException: not speak to master and retries used up

堆栈跟踪在这里：

Caused by: com.mongodb.MongoException: not talking to master and retries used up
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:314)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:316)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:257)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:310)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:295)
at com.mongodb.DBCursor._check(DBCursor.java:368)
at com.mongodb.DBCursor._hasNext(DBCursor.java:459)
at com.mongodb.DBCursor._fill(DBCursor.java:518)
at com.mongodb.DBCursor.toArray(DBCursor.java:553)
at com.mongodb.DBCursor.toArray(DBCursor.java:542)
at org.grails.datastore.mapping.mongo.query.MongoQuery$MongoResultList.<init>(MongoQuery.java:908)
at org.grails.datastore.mapping.mongo.query.MongoQuery$36.doInDB(MongoQuery.java:536)
at org.grails.datastore.mapping.mongo.query.MongoQuery$36.doInDB(MongoQuery.java:508)

我已经设置了一个本地测试环境来复制这个问题。这是配置输出：

{
"set" : "rsMesh",
"date" : ISODate("2013-09-10T01:08:20Z"),
"myState" : 2,
"syncingTo" : "macbookpro.local:27018",
"members" : [
    {
        "_id" : 1,
        "name" : "macbookpro.local:27018",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 9940,
        "optime" : {
            "t" : 1378767619,
            "i" : 5
        },
        "optimeDate" : ISODate("2013-09-09T23:00:19Z"),
        "lastHeartbeat" : ISODate("2013-09-10T01:08:19Z"),
        "lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
        "pingMs" : 0
    },
    {
        "_id" : 2,
        "name" : "macbookpro.local:27019",
        "health" : 1,
        "state" : 7,
        "stateStr" : "ARBITER",
        "uptime" : 9914,
        "lastHeartbeat" : ISODate("2013-09-10T01:08:19Z"),
        "lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
        "pingMs" : 0
    },
    {
        "_id" : 3,
        "name" : "macbookpro.local:27017",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 10392,
        "optime" : {
            "t" : 1378767619,
            "i" : 5
        },
        "optimeDate" : ISODate("2013-09-09T23:00:19Z"),
        "self" : true
    }
],
"ok" : 1

}

已根据文档在 Datasource.groovy 中设置了副本集配置：

grails {
mongo {
    replicaSet = ["macbookpro.local:27017", "macbookpro.local:27018", "macbookpro.local:27019"]
}

}

所以我没有独立运行，副本集服务器已正确同步，并且所有服务器都正常运行。但是，如果我强制一个新服务器成为主服务器，那么所有访问似乎都会失败，就好像驱动程序没有将查询重定向到新的主服务器一样。

我错过了什么？

【问题讨论】：

标签： mongodb grails

【解决方案1】：

没有人回答这个问题，所以我认为从副本集恢复是无效的。相反，我转而使用分片，并希望在应用服务器和集群本身之间分层一个 mongos 将提供足够的保护。

答案是确定的“某种”。之前，当我让一个主节点下线（或模拟崩溃）时，应用服务器会无限期地挂起。现在我只是收到一些关于在给定集群中找不到主节点的错误，然后系统恢复了。这不是一个理想的解决方案，但至少比永久失败要好。

【讨论】：