[
https://issues.apache.org/jira/browse/OAK-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14074477#comment-14074477
]
Chetan Mehrotra commented on OAK-1453:
--------------------------------------
For reference from this
[thread|https://groups.google.com/d/msg/mongodb-user/qSi8RmvcAUY/PjvrMGpeHDcJ]
bq. Now, if you are getting back success for the write and you are using
writeConcern w:1 (acknowledged) but during the data load you are losing the
primary, *unless you have used w:2 as write concern (waiting for replication to
at least one other node before acknowledgement) you will potentially have some
records that would be written to the primary, not replicated and then if you
shut down the primary and another node becomes the primary, the original node
will have to roll back that write (since it's not on the new primary)*. If
that's what happened, you will be able to find a "rollback" directory in the
data directory which will have the documents that were rolled back.
> MongoMK failover support for replica sets (esp. shards)
> -------------------------------------------------------
>
> Key: OAK-1453
> URL: https://issues.apache.org/jira/browse/OAK-1453
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
> Reporter: Michael Marth
> Assignee: Thomas Mueller
> Labels: production, resilience
> Fix For: 1.1
>
>
> With OAK-759 we have introduced replica support in MongoMK. I think we still
> need to address the resilience for failover from primary to secoandary:
> Consider a case where Oak writes to the primary. Replication to secondary is
> ongoing. During that period the primary goes down and the secondary becomes
> primary. There could be some "half-replicated" MVCC revisions, which need to
> be either discarded or be ignored after the failover.
> This might not be an issue if there is only one shard, as the commit root is
> written last (and replicated last)
> But with 2 shards the the replication state of these 2 shards could be
> inconsistent. Oak needs to handle such a situation without falling over.
> If we can detect a Mongo failover we could query Mongo which revisions are
> fully replicated to the new primary and discard the potentially
> half-replicated revisions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
