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

Ensure getLastErrorDefaults/getLastErrorModes are satisfiable

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.5.4
    • Component/s: Replication
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      Repl 2017-02-13

      Description

      The server should not accept (at initiate or reconfig) replica set configs that specify a value for getLastErrorDefaults.w which is greater than the number of data bearing members, eg:

      {
          "_id" : "replset",
          "version" : 1,
          "members" : [
              {
                  "_id" : 0,
                  "host" : "localhost:27017",
                  "priority" : 1
              }
          ],
          "settings" : {
              "getLastErrorDefaults" : {
                  "w" : 2
              }
          }
      }
      

      This is because such configs are self-contradictory — they specify a replica set which cannot acknowledge "plain" (no write concern) writes. Unless they happen to explicitly specify a sensible w value, ordinary write ops/GLE will appear to mysteriously hang. This includes very simple things like "db.foo.insert({})" and mongorestore/mongoimport.

      The desired behaviour is that a replSetInitiate or replSetReconfig command with such a config should result in an error like the following (ala SERVER-13055):

      {
          "ok" : 0,
          "errmsg" : "Default write concern mode cannot wait for more than the number of data bearers",
          "code" : 103
      }
      

      Note that this ticket is NOT asking to forbid a write or getLastError from being able to specify a w value greater than the number of data bearers. Since such operations are independent of the replset config they are not self-contradictory, they are a valid thing for a write to request (irrespective of the set's current ability to satisfy it), and can easily be acknowledged if the replset is suitably reconfig'd.

      By contrast, it is non-sensical to declare a replset that has N data bearers and a normal/default write concern of > N. The only way to fix such a situation is to reconfig — highlighting that the config should never have been accepted in the first place.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: