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

slaveok versioning logic in mongos should also apply to read prefs

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 2.4.9, 2.5.5
    • Affects Version/s: 2.4.8
    • Component/s: Sharding
    • None
    • ALL

      Issue Status as of January 8th, 2014

      ISSUE SUMMARY
      Mongos does not treat non-primary only read preferences the same as slaveOk.

      This issue is part of 4 related issues which impact cluster availability when there is no primary available for a shard. See SERVER-7246, SERVER-5625, SERVER-11971 and SERVER-12041 for more details.

      USER IMPACT
      Non-primary read preferences (without slaveOk set) are not tolerant of the primary being down after splits or migrations have occurred. This will cause existing connections to fail in the event that the primary is unavailable.
      It is present in versions of MongoDB prior to and including v2.4.8.

      SOLUTION
      Treat non-primary only read preferences the same as if slaveOk is set.

      WORKAROUNDS
      Set the slaveOk bit as well as the non-primary only read preference in the client application.

      PATCHES
      Production release v2.4.9 contains the fix for this issue, and production release v2.6.0 will contain the fix as well.

      Original Description

      When running a slaveok query on mongos which (potentially) talks to secondary nodes, we attempt to set the shard version on the connection but tolerate failure. The slaveok flag is not necessarily set when read preferences are used, but the same logic should apply.

      Not a regression, but needs improvement.

            Assignee:
            greg_10gen Greg Studer
            Reporter:
            greg_10gen Greg Studer
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: