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

Ensure getLastErrorDefaults/getLastErrorModes are satisfiable

    • Type: Icon: Improvement Improvement
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 3.5.4
    • Affects Version/s: None
    • Component/s: Replication
    • Fully Compatible
    • Repl 2017-02-13

      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.

            Assignee:
            matthew.russotto@mongodb.com Matthew Russotto
            Reporter:
            kevin.pulo@mongodb.com Kevin Pulo
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: