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

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Duplicate
    • Affects Version/s: 2.4.10
    • Fix Version/s: None
    • Component/s: Querying
    • Labels:
      None
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      see above

      Show
      see above

      Description

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

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: