[DOCS-6237] claims about read and write concerns are vague or too strong Created: 18/Sep/15  Updated: 24/Feb/16  Resolved: 17/Dec/15

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: mongodb-3.0
Fix Version/s: None

Type: Task Priority: Minor - P4
Reporter: Mark Callaghan Assignee: Kay Kim (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 8 years, 8 weeks, 6 days ago

 Description   

Fixing this is likely to make users happier and avoid bad PR, as incorrect and too strong claims in the docs were part of the motivation for the Call Me Maybe posts about MongoDB.


From http://docs.mongodb.org/master/core/write-concern/
"With replica acknowledged write concern, you can guarantee that the write operation propagates to additional members of the replica set"

That is not guaranteed. The feature provided is that writes are not acknowledged until a majority of the replica set has received the change. But there is no guarantee that the change reaches a majority as the master can fail while waiting for that to happen.


From http://docs.mongodb.org/master/core/replica-set-write-concern/
"Use of insufficient write concern can lead to rollbacks in the case of replica set failover. Always ensure that your operations have specified the required write concern for your application."

There are at least 3 types of rollbacks:
1) committed to master, visible to nobody, not acknowledged
2) committed to master, visible to somebody, not acknowledged
3) committed to master, visible to nobody, acknowledged
4) committed to master, visible to somebody, acknowledged

For #1, we can pretend the commit didn't happen and rollback doesn't matter.

Write concern majority avoids #3 and #4

Write concern majority doesn't prevent #2. Read concern majority in 3.2 will help with that.


From http://docs.mongodb.org/master/applications/replication/
"In MongoDB, clients can see the results of writes before they are made durable:
Regardless of write concern, other clients can see the result of the write operations before the write operation is acknowledged to the issuing client."

This is only true for mmapv1


http://docs.mongodb.org/master/core/replica-set-rollbacks/
"Regardless of write concern, other clients can see the result of the write operations before the write operation is acknowledged to the issuing client."

I forgot the answer. Does WiredTiger release its equivalent of row locks while waiting for secondaries to acknowledge?


From http://docs.mongodb.org/master/reference/write-concern/
"Confirms that write operations have propagated to the majority of voting nodes: a majority of the replica set’s voting members must acknowledge the write operation before it succeeds. This allows you to avoid hard coding assumptions about the size of your replica set into your application."

I would change the first sentence to "Confirms that write operations have propagated to the majority of voting nodes before acknowledging the write". As written the first part of the sentence claims something stronger. I also assume that "reach" means that secondaries have the change in their log, but might not have applied the change. So a read on the secondary after doing the write on the master might not see the change.



 Comments   
Comment by Kay Kim (Inactive) [ 17/Dec/15 ]

Thanks Mark! We've cleaned up the write concerns a bit (we seemed to have sprinkled sentences here and there) and tried to tidy up where we talk about it. As for your question about WT, yes to releasing its equivalent of row locks. We'll continue to streamline and remove ambiguities to provide a clearer, more coherent information.

Regards,

Kay Kim

Comment by Kay Kim (Inactive) [ 18/Sep/15 ]

Thanks so much. Appreciated as always. Scheduled for next sprint which starts on Monday.

Generated at Thu Feb 08 07:51:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.