Aerospike cluster behavior in different consistency mode?

Operations Configuration
1

I want to understand the behavior of aerospike in different consistancy mode.

Consider a aerospike cluster running with 3 nodes and replication factor 3.

AP modes is simple and it says

Aerospike will allow reads and writes in every sub-cluster.

And Maximum no. of node which can go down < 3 (replication factor)

For aerospike strong consistency it says

Note that the only successful writes are those made on replication-factor number of nodes. Every other write is unsuccessful

Does this really means the no writes are allowed if available nodes < replication factor.

And then same document says

All writes are committed to every replica before the system returns success to the client. In case one of the replica writes fails, the master will ensure that the write is completed to the appropriate number of replicas within the cluster (or sub cluster in case the system has been compromised.)

what does appropriate number of replica means ?

So if I lose one node from my 3 node cluster with strong consistency and replication factor 3 , I will not be able to wright data ?

2

Cross post on stack overflow.

You are correct, with 3 nodes and RF 3, losing one node means the cluster will not be able to successfully take write transactions since it wouldn’t be able to write the required number of copies (3 in this case).

Appropriate number of replicas means a number of replicas that would match the replication factor configured.

3

But this is not the case in AP mode right ?

4

Correct, this is only for strong consistency configured namespaces.

5

What happens when a node or two is down / unreachable in 3 node AP namespace with RF 3 , write succeed immediately or does it try to write to other node and wait for sometime and then succeed ?

And does the node which was down get the data once up ?

6

In AP, when there are fewer than RF nodes, the RF is reduced to the current cluster size.

When nodes return, the RF will return to the configured value and migrations will catch the returning nodes up. For active transactions, duplicate resolution will resolve conflicting copies of records from the nodes present in the cluster using the configured conflict-resolution-policy.

7

We believe it is the correct choice to not allow a write at a certain replication factor, if you don’t have that number of replicas. People choose replication factor for guaranteed durability, and if you can’t guarantee that durability, you should fail the write.