Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-14781

ReadPreference.secondaryPreferred doesn't failover if secondary in "recovering state"

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Critical - P2 Critical - P2
    • None
    • Affects Version/s: 2.4.10
    • Component/s: Querying
    • None
    • ALL
    • Hide

      see above

      Show
      see above

      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
                      }
              ],
      

            Assignee:
            Unassigned Unassigned
            Reporter:
            apiggott@ikanow.com Alex Piggott
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: