[ 
https://issues.apache.org/jira/browse/OAK-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976109#comment-14976109
 ] 

Chetan Mehrotra commented on OAK-3554:
--------------------------------------

Some more thoughts - It might happen that setting w:majority globally for 
*every* write can lead to significant performance loss. We can probably look 
into using a higher write concern for more critical writes. For example writes 
which mark a revision as committed on commit root can be set with w:majority 
while at other places we use default write concern.

Per [1] write concern relies on replication log i.e. writes are not sent to 
individual servers directly but instead are pushed to replication log and then 
from there the call would wait untill a write op with a specific concern 
matches the required

[1] https://docs.mongodb.org/manual/core/replica-set-write-concern/

> Use write concern of w:majority when connected to a replica set
> ---------------------------------------------------------------
>
>                 Key: OAK-3554
>                 URL: https://issues.apache.org/jira/browse/OAK-3554
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: mongomk
>            Reporter: Chetan Mehrotra
>             Fix For: 1.3.10
>
>
> Currently while connecting to Mongo MongoDocumentStore relies on default 
> write concern provided as part of mongouri. 
> Recently some issues were seen where Mongo based Oak was connecting to 3 
> member replica set and there were frequent replica state changes due to use 
> of VM for Mongo. This caused data loss and corruption of data in Oak.
> To avoid such situation Oak should default to write concern of majority by 
> default. If some write concern is specified as part of mongouri then that 
> should take precedence. This would allow system admin to take the call of 
> tweaking write concern if required and at same time allows Oak to use the 
> safe write concern.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to