[SERVER-18407] Ensure getLastErrorDefaults/getLastErrorModes are satisfiable Created: 11/May/15  Updated: 11/Apr/17  Resolved: 13/Feb/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.5.4

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Matthew Russotto
Resolution: Done Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-14567 Implement checkIfWriteConcernCanBeSat... Closed
related to SERVER-28729 Ensure getLastErrorModes with replica... Backlog
related to SERVER-13055 Shouldn't allow w:0 in replset getLas... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2017-02-13
Participants:

 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.



 Comments   
Comment by Githook User [ 13/Feb/17 ]

Author:

{u'username': u'mtrussotto', u'name': u'Matthew Russotto', u'email': u'matthew.russotto@10gen.com'}

Message: SERVER-18407 Fix message delimiters in earlier fix.
Branch: master
https://github.com/mongodb/mongo/commit/9fbc330414f316de594ebc62fe52e9956ea8be00

Comment by Githook User [ 13/Feb/17 ]

Author:

{u'username': u'mtrussotto', u'name': u'Matthew Russotto', u'email': u'matthew.russotto@10gen.com'}

Message: SERVER-18407 Add check to ensure write concern is satisfiable in initial config
Branch: master
https://github.com/mongodb/mongo/commit/05f489418593db35aef28040079ef57829e11f66

Generated at Thu Feb 08 03:47:34 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.