Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
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.
xgen-internal-githook commented on Wed, 15 Nov 2017 15:55:11 +0000: Author: {'name': 'Katherine Walker', 'username': 'kvwalker', 'email': 'katherine.walker@mongodb.com'} Message: SERVER-29649 Add startupWarning for replset running with --nojournal when writeConcernMajorityJournalDefault is not false (cherry picked from commit 5fe40b170094b08ead496eb694113892bb711373) Branch: v3.4 https://github.com/mongodb/mongo/commit/e0459c3793fd6cebd066a594c50e39cb3378ff69 xgen-internal-githook commented on Mon, 30 Oct 2017 16:32:56 +0000: Author: {'email': 'katherine.walker@mongodb.com', 'name': 'Katherine Walker', 'username': 'kvwalker'} Message: SERVER-29649 Add startupWarning for replset running with --nojournal when writeConcernMajorityJournalDefault is not false (cherry picked from commit 5fe40b170094b08ead496eb694113892bb711373) Branch: v3.2 https://github.com/mongodb/mongo/commit/918524be973eb056909f035df141b0dd5765ead1 xgen-internal-githook commented on Mon, 2 Oct 2017 14:22:53 +0000: Author: {'email': 'katherine.walker@mongodb.com', 'name': 'Katherine Walker', 'username': 'kvwalker'} Message: SERVER-29649 Add startupWarning for replset running with --nojournal when writeConcernMajorityJournalDefault is not false Branch: master https://github.com/mongodb/mongo/commit/5fe40b170094b08ead496eb694113892bb711373 xgen-internal-githook commented on Wed, 27 Sep 2017 13:07:46 +0000: Author: {'email': 'ian.whalen@gmail.com', 'name': 'Ian Whalen', 'username': 'IanWhalen'} Message: Revert "SERVER-29649 Add startupWarning for replset running with --nojournal when writeConcernMajorityJournalDefault is not false" This reverts commit db986c959a8e080d038577ae107af60bf2611557. Branch: master https://github.com/mongodb/mongo/commit/b81d9c960435f36cbd67ec592b5372d45199cf90 xgen-internal-githook commented on Tue, 26 Sep 2017 21:29:03 +0000: Author: {'email': 'katherine.walker@mongodb.com', 'name': 'Katherine Walker', 'username': 'kvwalker'} Message: SERVER-29649 Add startupWarning for replset running with --nojournal when writeConcernMajorityJournalDefault is not false Branch: master https://github.com/mongodb/mongo/commit/db986c959a8e080d038577ae107af60bf2611557 spencer commented on Mon, 17 Jul 2017 20:57:53 +0000: FYI benety.goh ian@10gen.com commented on Mon, 17 Jul 2017 19:36:53 +0000: Sounds like this ticket should be repurposed to add a warning as suggested by David in the previous comment. david.daly commented on Thu, 15 Jun 2017 20:27:47 +0000: 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. schwerin commented on Thu, 15 Jun 2017 15:16:53 +0000: 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.
./mongod --replSet=test --nojournal In the mongo shell: rs.initiate() db.test.insert({}) db.test.drop() db.runCommand("listCollections", {includePendingDrops: true})