[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.
2) Client 2 views commit from client 1 by doing read on master.
3) Master reboots.
4) Replica 2 elected new master, it didn't get oplog entry from step 1
5) Old master comes back, does rollback to remove change from step 1



 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?

  • A secondary (that was previously a primary) contains write operations that are ahead of the current primary
  • A secondary lags behind the primary by 2 hours or more
  • A secondary lags behind the primary by 100 writes or more
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: DOCS-5185 forgot to append the before returning with acknowledgement clause
Branch: master
https://github.com/mongodb/docs/commit/e2602245a3d447a633c0168541f3a1f6527ff852

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: DOCS-5185 forgot to append the before returning with acknowledgement clause
Branch: v2.6
https://github.com/mongodb/docs/commit/4df8683158342fc8cad95f844b0c5af3c78dfeff

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: DOCS-5185 replica set rollback clarification
Branch: v2.6
https://github.com/mongodb/docs/commit/ce51a55e8ec5c5e3b18823e10e9aae92fe9e91a4

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: DOCS-5185 replica set rollback clarification
Branch: master
https://github.com/mongodb/docs/commit/7903fd3f850a42636b3e9daa61f7182c02d1ac6b

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).
Please note the linked discussion is based on older versions of MongoDB which did not use election times, etc. to resolve some conflict situations.

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/

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