[SERVER-29649] Add startupWarning when a replset node is running with --nojournal but hasn't set writeConcernMajorityJournalDefault to false Created: 15/Jun/17 Updated: 30/Oct/23 Resolved: 02/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.2.18, 3.4.11, 3.6.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | David Daly | Assignee: | Katherine Walker (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v3.4, v3.2
|
||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: |
In the mongo shell:
|
||||||||||||||||||||||||||||||||||||
| Sprint: | Repl 2017-07-31, Repl 2017-10-02 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||||||||||||||
| Description |
|
If a replica set is running without journaling it should set the writeConcernMajorityJournalDefault in the replica set config to false. If this isn't done there will be multiple issues, including that w:majority write concerns will never complete and that two-phase collection drops will never actually drop the actual underlying WT tables. |
| Comments |
| Comment by Githook User [ 15/Nov/17 ] |
|
Author: {'name': 'Katherine Walker', 'username': 'kvwalker', 'email': 'katherine.walker@mongodb.com'}Message: (cherry picked from commit 5fe40b170094b08ead496eb694113892bb711373) |
| Comment by Githook User [ 30/Oct/17 ] |
|
Author: {'email': 'katherine.walker@mongodb.com', 'name': 'Katherine Walker', 'username': 'kvwalker'}Message: (cherry picked from commit 5fe40b170094b08ead496eb694113892bb711373) |
| Comment by Githook User [ 02/Oct/17 ] |
|
Author: {'email': 'katherine.walker@mongodb.com', 'name': 'Katherine Walker', 'username': 'kvwalker'}Message: |
| Comment by Githook User [ 27/Sep/17 ] |
|
Author: {'email': 'ian.whalen@gmail.com', 'name': 'Ian Whalen', 'username': 'IanWhalen'}Message: Revert " This reverts commit db986c959a8e080d038577ae107af60bf2611557. |
| Comment by Githook User [ 26/Sep/17 ] |
|
Author: {'email': 'katherine.walker@mongodb.com', 'name': 'Katherine Walker', 'username': 'kvwalker'}Message: |
| Comment by Spencer Brody (Inactive) [ 17/Jul/17 ] |
|
FYI benety.goh |
| Comment by Ian Whalen (Inactive) [ 17/Jul/17 ] |
|
Sounds like this ticket should be repurposed to add a warning as suggested by David in the previous comment. |
| Comment by David Daly [ 15/Jun/17 ] |
|
Discussed offline with schwerin. Re-opening this ticket, with the intention that MongoD should give a useful warning in this case, probably as part of the rs.initiate() call. It should either warn or refuse to initiate if the host cannot commit majority writes. |
| Comment by Andy Schwerin [ 15/Jun/17 ] |
|
Nodes running with --nojournal cannot be used to satisfy w:majority writes unless the replica set configuration includes writeConcernMajorityJournalDefault: false. That field governs when a w:majority write is considered to have committed. If you set it to false, the writes don't need to be durable on disk. The default is true, as it lets systems recover from more kinds of failures. Running with --nojournal and setting the writeConcernMajorityJournalDefault: false is not recommended, because it means that you can lose confirmed w:majority writes if the majority of the nodes in your replica set crash and get restarted. That's OK for some use cases, but not all, and users would need to carefully consider their application requirements. Due to implementation complexity, replication doesn't currently use wired tiger checkpoint information to determine write durability; it only uses the wired tiger journal. It would be possible, hypothetically, but is a ton of work. Users who care about durability to disk and the failure modes it improves get better operation latency for w:majority writes from journaling, anyhow. |