[DOCS-5185] MongoDB does not guarantee that rollback doesn't happen Created: 08/Apr/15 Updated: 22/Apr/15 Resolved: 10/Apr/15 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | mongodb-2.6, mongodb-3.0 |
| Type: | Improvement | Priority: | Major - P3 |
| 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, 43 weeks ago |
| Description |
|
This is claimed in docs at http://docs.mongodb.org/manual/core/replica-set-rollbacks/ and in the quiz for the Recovery section of M102. It isn't true. From the docs: "To prevent rollbacks, use replica acknowledged write concern to guarantee that the write operations propagate to the members of a replica set." From M102: "MongoDB has a method to ensure a write was replicated and will never need to be rolled back:" Failure scenario in which commit was visible to another client on the master and then is removed during rollback. 1) Client 1 commits to journal on master and waits. |
| Comments |
| Comment by Shannon Bradshaw (Inactive) [ 22/Apr/15 ] |
|
Revisiting this lesson, the existing quiz is not terribly on point even if it were correct. We've updated as follows. Which of the following scenarios can trigger a rollback?
|
| Comment by Githook User [ 10/Apr/15 ] |
|
Author: {u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message: |
| Comment by Githook User [ 10/Apr/15 ] |
|
Author: {u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message: |
| Comment by Githook User [ 10/Apr/15 ] |
|
Author: {u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message: |
| Comment by Githook User [ 10/Apr/15 ] |
|
Author: {u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message: |
| Comment by Mark Callaghan [ 09/Apr/15 ] |
|
Can someone change "happy" to "happen" in the title? |
| Comment by Mark Callaghan [ 09/Apr/15 ] |
|
That would be much better. |
| Comment by Asya Kamsky [ 09/Apr/15 ] |
|
Right, that should say instead: "To prevent rollbacks of data that has been acknowledged to the client, use replica acknowledged write concern to guarantee that the write operations propagate to the members of a replica set before the acknowledgement is received." (or something like that). |
| Comment by Mark Callaghan [ 08/Apr/15 ] |
|
Using the claim from the docs, this is not guaranteed. It is true that an ack'd write won't be subject to rollback after the ack has been received. Prior to that lots of fun things can happen. "To prevent rollbacks, use replica acknowledged write concern to guarantee that the write operations propagate to the members of a replica set." |
| Comment by Mark Callaghan [ 08/Apr/15 ] |
|
The behavior is that you can use a write concern so that an ack'd write won't be open to rollback. But that isn't what has been claimed. This is async replication and changes visible to others will be subject to rollback. You need sync replication (or lossless semi-sync as done in MySQL) to avoid that risk. |
| Comment by Asya Kamsky [ 08/Apr/15 ] |
|
Note that the docs don't say that it won't be visible till it's acknowledged - there is no "read replica committed" (yet). It's saying that if a write is acknowledged to the client then it won't be rolled back (and that's true unless there is a bug in the implementation). |
| Comment by Mark Callaghan [ 08/Apr/15 ] |
|
This might be background reading - http://www.tokutek.com/2014/07/introducing-ark-a-consensus-algorithm-for-tokumx-and-mongodb/ |