Having a cluster with 4 data nodes, bucket with 1 replica, and transaction durability set to MAJORITY, and 1 failed-over node, we are facing below exception:

HTTP 500 Internal Server Error: Transaction failed: Transaction has failed with cause 'com.couchbase.client.core.error.DurabilityImpossibleException: With the current cluster configuration, the requested durability guarantees are impossible {“clientContext”:


Increasing replica to 2 seems to have solved the issue. We are guessing setting durability to NONE might do the trick too, but this does not seem to be a reasonable setting, right?

What are the guidelines regarding this error with our current architecture?

We understand in case we have 2 failed-over nodes and 2 replicas we will face the error again? so requesting 3 number of replicas, being the max number possible, is it a recommended option? what other guidelines can we follow?

Please find screenshot attached:

Thanks in advance

This is a physical limitation of needing enough nodes to do the replication, and it seems like you have this figured out. When a node fails it should be replaced as soon as possible. If you are experiencing multiple simultaneous failed-over nodes, you should consider hosting your servers elsewhere. Three replicas is not supported with Durability.Majority ( Durability | Couchbase Docs )

One thing you could consider - depending on the importance of the data - is having your application retry the operation with less or no replication. This will only help if the bucket has a lower replication.

1 Like

In addition to what Michael says above, you are correct - this isn’t a supported setting for transactions as without durability you no longer have ACID guarantees.

1 Like

What is the recommended cluster setting for local couchbase instance when developing/testing transactions? Why is there no ACID guarantees if durability is set to NONE?

You can use any of the durability settings when testing locally. Just note the “Single Node Cluster” section at the top of Using Couchbase Transactions | Couchbase Docs.

For the second question, it’s because it provides the (D)urability portion of the ACID guarante. With durable writes, once the service acknowledges that a key has been written, then it’s guaranteed to remain written as long as a majority of nodes continue to be available. Please see Durability | Couchbase Docs for more information on durable writes in general.

In the Java SDK, I haven’t been able to find a way to specify the “honor the bucket’s durability level” option or set the durability level to null. I’ve reviewed the documentation, but it’s still unclear to me what the appropriate configurations should be.

One aspect that confuses me is the statement in the durability documentation that if the number of replicas is 0, the number of nodes for majority is one. However, when we use DurabilityLevel.MAJORITY with 0 replicas, it results in a DurabilityImpossibleException. I would expect a single cluster node to work with 0 replicas and DurabilityLevel.MAJORITY. Could you please provide some clarification on this?

For the DurabilityImpossibleException, please see the link “Single Node Cluster” section mentioned above.

For the bucket minimum durability level, I believe the durability level used will be the maximum of this and what you specify in the SDK.