[ 
https://issues.apache.org/jira/browse/OAK-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Reutegger resolved OAK-1453.
-----------------------------------
       Resolution: Won't Fix
    Fix Version/s:     (was: 1.6)

I'm resolving this issue as WONTFIX because the proposed behaviour is very 
difficult and complex to implement property, confusing for an API consumer and 
contradicts what was implemented for OAK-2592 and OAK-3554.

The recommended deployment is a replica set with at least three members and a 
majority write concern. With this setup (even when using shards) a write will 
only succeed when it is replicated to at least one secondary. This means a 
successful write operation survives even a primary crash. With this deployment 
the proposed rollback mechanism in Oak is not needed.

Even if such a rollback is desired from a backend POV, the consequences for an 
Oak or JCR API consumer is rather dangerous and confusing because ACID 
properties do not hold anymore.

> 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
>              Labels: production, resilience
>
> 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.3.4#6332)

Reply via email to