[DOCS-11447] Documentation of "linearizable" read concern misstates writeConcernMajorityJournalDefault:false behavior Created: 13/Mar/18  Updated: 30/Oct/23  Resolved: 16/Mar/18

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Bug Priority: Critical - P2
Reporter: Andy Schwerin Assignee: Ravind Kumar (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 5 years, 47 weeks, 5 days ago
Story Points: 0.1

 Description   

The documentation of linearizable read concern contains the following incorrect statement:

With `writeConcernMajorityJournalDefault` set to false, MongoDB will not wait for `w: "majority"` writes to be durable before acknowledging the writes. As such, "majority" write operations could possibly roll back in the event of a loss of a replica set member.

But this is not quite right. Rather, the last sentence of the above paragraph should read:

As such, "majority" write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set.



 Comments   
Comment by Githook User [ 16/Mar/18 ]

Author:

{'email': 'ravind.kumar@10gen.com', 'name': 'ravind', 'username': 'rkumar-mongo'}

Message: DOCS-11447: Improve docs on linearizable read concern
Branch: v3.4
https://github.com/mongodb/docs/commit/56bcf64b9d7711bd75a6e34710bcfb0535fe65e6

Comment by Githook User [ 16/Mar/18 ]

Author:

{'email': 'ravind.kumar@10gen.com', 'name': 'ravind', 'username': 'rkumar-mongo'}

Message: DOCS-11447: Improve docs on linearizable read concern
Branch: master
https://github.com/mongodb/docs/commit/ba1958bc62feaff64cff3e44a14ceadb22763014

Comment by Ravind Kumar (Inactive) [ 16/Mar/18 ]

RFM

Comment by Andy Schwerin [ 14/Mar/18 ]

I'd remove the third sentence. It either is obvious (writes that start after the read completes aren't visible in the read) or isn't guaranteed (writes that start after the read starts and complete before the read completes might be visible to the read).

I'd replace the second sentence with something less about the implementation and more about the risk – the query may wait for concurrently executing writes to complete before returning results.

Comment by Ravind Kumar (Inactive) [ 13/Mar/18 ]

The second sentence just makes the waiting behavior explicit. The third sentence was suggested by John Page, to emphasize that the write operations returned wont reflect any updates made after the read, even if they have occurred by the time the read operation returns. I don't think its a bad thing to emphasize, though I suppose it should be implied given we're only talking about write ops before the read anyways.

Comment by Andy Schwerin [ 13/Mar/18 ]

Re "writeConcernMajorityJournalDefault", you should probably check that the docs for that replica set config option are also correct.

RE the suggested copy, I suggest replacing "occurred" with "completed". The second sentence sounds like an implementation detail. Is it necessary? I don't know what the third sentence is for.

The query returns data that reflects all successful majority-acknowledged writes that occurred completed prior to the start of the read operation. The query waits for any writes that are not yet majority-acknowledged to propagate to a majority of replica set members, which can result in slow read operations. The returned data reflects the state of documents at the time of the read operation, and does not reflect any write operations that modified the record after the read operation.

Comment by Ravind Kumar (Inactive) [ 13/Mar/18 ]

Additional suggestion for the second sentence of the first paragraph:

If a majority of your nodes crash and restart, when writeConcernMajorityJournalDefault is set to true (the default), your confirmed w:majority writes survive

Comment by Ravind Kumar (Inactive) [ 13/Mar/18 ]

schwerin spencer cc alyson.cabral

Additionally, the first paragraph has inaccuracies regarding what write operations are returned, and can be interpreted incorrectly. Suggesting the following copy:

The query returns data that reflects all successful majority-acknowledged writes that occurred prior to the start of the read operation. The query waits for any writes that are not yet majority-acknowledged to propagate to a majority of replica set members, which can result in slow read operations. The returned data reflects the state of documents at the time of the read operation, and does not reflect any write operations that modified the record after the read operation.

Any objections?

Generated at Thu Feb 08 08:02:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.