two transient primaries can cause successful write with majority concern to rollback

[Zardosht Kasheff]

Hello all,

I've attached a js test that shows an issue with two transient
primaries: a write that succeeded with write concern majority is
rolled back. In fact, this test case can be used to show that a write
that succeeds with write concern of n-1, where n is the number of
machines in the replica set, may still rollback.

Here is the issue. Suppose we have N machines in the replica set.
Machine A is primary. A gets disconnected from the set. B assumes
primary, but A has yet to step down. B then does a write and that
write is replicated to all n-1 machines (all machines except A). But A
has yet to step down. A then reconnects to the set. Now we have two
transient primaries, A and B.

In this scenario, if B steps down, and A remains primary, then the
write that B did and replicated to all other machines while A was
disconnected will rollback.

Unfortunately, I don't have a proposed solution to this problem. It
seems that if there are two primaries, it's impossible to know which
to select in a manner that ensures no write that succeeded with
majority write concern is rolled back.

-Zardosht

[Alexander Sahler]

Hi.

As this post is quite old, does it apply still? Which version did you apply the test to? Has it been fixed in the meantime? Does it apply to TokuMX as well?

Regards, Alexander

[Andy Schwerin]

For replica sets where all members clocks are sychronized to within about 30 seconds of one another, the fix for SERVER-9765 should cover the scenario described by Zardosht. That fix is in all versions of MongoDB 2.6 and later. In MongoDB 3.2, the same fix applies, but no longer requires synchronized clocks if the replica set is running the new election protocol. This is because in SERVER-18717 we began deriving the election id from the election term number in the new election protocol.

A white paper describing the new election protocol is forthcoming. In summary, it takes the term numbering and randomized election timer concepts from Raft, but keeps the pull-based replication strategy of the existing protocol in order to support chaining.

-Andy

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-dev...@googlegroups.com.
To post to this group, send email to mongo...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-dev.
For more options, visit https://groups.google.com/d/optout.

[Alexander Sahler]

Thank you very much for your answer! I'll try to test my application thoroughly against this scenario.

-Alexander