[JAVA-1309] REPLICA_ACKNOWLEDGED not working at the time of arbiter Node Created: 09/Jul/14  Updated: 13/Aug/14  Resolved: 13/Aug/14

Status: Closed
Project: Java Driver
Component/s: Write Operations
Affects Version/s: 2.12.2
Fix Version/s: None

Type: Bug Priority: Blocker - P1
Reporter: Kaliraj Assignee: Ross Lawley
Resolution: Done Votes: 0
Labels: driver
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux OS


Attachments: Java Source File DatabaseUtil.java    

 Description   

I have 3 mongodb node setup like Primary, Secondary and an Arbiter.
In this case, if Secondary node is down then Write Concern REPLICA_ACKNOWLEDGED is not working. It is trying to replicate data with second node. But Arbiter node doesn't have data replication. So i am unable to read the data from primary node due to Primary node gets locked at the time of write operation which is not acknowledge by secondary node.



 Comments   
Comment by Ross Lawley [ 13/Aug/14 ]

Hi kalirajb I don't think there anything else I can do to help with this ticket.

I have noted a server ticket that may be of interest and worth voting for SERVER-14539 which would help ensure acknowledged if the secondary went down in your replicaset.

Comment by Ross Lawley [ 09/Jul/14 ]

Hi kalirajb,

I can't reproduce that it is blocking, as waiting for write concern result yields the lock - so that other processes can continue to write and read. However, if all your processes are using the same write concern then each one will block until the write concern is satisfied or the operation it times out.

For your setup 1 Primary, 1 Secondary and 1 Arbiter this write concern ensures you have two copies of your data. However, it has the fail case of a single node, so to improve resiliency replacing the arbiter with a secondaries would be better for this write concern.

You can change the Write Concern at any time using the setWriteConcern() method on the MongoClient, Database or Collection. However, the overhead of checking the replica set status to see if a Secondary is down, would be prohibitive. Given your configuration and if acknowledged writes are acceptable when there is only a single data node - wouldn't that be a better default?

Ross

Comment by Kaliraj [ 09/Jul/14 ]

Hi Ross,

Yes, i am unable to write or read with other Threads due to MongoDB Database lock(in 2.4.X)/ collection lock(in 2.6.X) at the time of write concern. So it wouldn't allow for other Thread to Read or Write in Primary Node.
In this case, i am explicitly mentioned that need to replicate data to secondary node. Because my write should be in primary and read preference should be in secondary for improve my application performance.

Is there anything, i can dynamically change Write concern from REPLICA_ACKNOWLEDGED to ACKNOWLEDGED at the time of secondary node is down?

Kaliraj

Comment by Ross Lawley [ 09/Jul/14 ]

Hi kalirajb,

Your correct - the semantics for REPLICA_ACKNOWLEDGED are:

With replica acknowledged write concern, you can guarantee that the write operation propagates to additional members of the replica set.

replica-acknowledged

So as you have a 3 node replicaSet with an arbiter and the Secondary is down then it is impossible for the operation to propagate to other members of the replicaSet until the Secondary comes online again and can start replicating again. The arbiter node is passive and only takes part in the election process for declaring primaries.

For more information see the Write Concern for Replica Sets documentation.

Any write with a write concern will block that thread until the write concern is satisfied or it has timed out. However, other threads should still be able to read and write from the database.

Is that not what you are seeing?

Ross

Generated at Thu Feb 08 08:54:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.