-
Type:
Bug
-
Resolution: Duplicate
-
Priority:
Critical - P2
-
None
-
Affects Version/s: 2.4.10
-
Component/s: Querying
-
None
-
ALL
-
I use the Java driver to query the database like this:
docdCursor = docDb.find(query, fields).batchSize(nFromServerLimit).setReadPreference(ReadPreference.secondaryPreferred());
In one particular cluster, I have a sharded DB with 1 shard of 2 replicas and an arbiter (see rs.status at the bottom) - the secondary is in state RECOVERING
I would therefore expect to see my reads all go to the primary. In fact they were being routed to the secondary resulting in errors returning from the above reads (referencing the fact that the queried node was recovering)
When I changed my config so that all reads went to the primary, the problems disappeared
"members" : [
{
"_id" : 0,
"name" : "192.168.8.106:27018",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 133328,
"optime" : Timestamp(1407176295, 181),
"optimeDate" : ISODate("2014-08-04T18:18:15Z"),
"lastHeartbeat" : ISODate("2014-08-04T18:21:43Z"),
"lastHeartbeatRecv" : ISODate("2014-08-04T18:21:43Z"),
"pingMs" : 0
},
{
"_id" : 1,
"name" : "192.168.8.108:27018",
"health" : 1,
"state" : 3,
"stateStr" : "RECOVERING",
"uptime" : 1729948,
"optime" : Timestamp(1406690192, 40),
"optimeDate" : ISODate("2014-07-30T03:16:32Z"),
"maintenanceMode" : -16,
"errmsg" : "still syncing, not yet to minValid optime 53db9bc5:34",
"self" : true
},
{
"_id" : 2,
"name" : "192.168.8.106:27218",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 133328,
"lastHeartbeat" : ISODate("2014-08-04T18:21:42Z"),
"lastHeartbeatRecv" : ISODate("2014-08-04T18:21:43Z"),
"pingMs" : 0
}
],
- duplicates
-
-
- Closed
-