[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/ 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/ There are at least 3 types of rollbacks: 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/ This is only true for mmapv1 http://docs.mongodb.org/master/core/replica-set-rollbacks/ 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/ 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. |