# Aerospike cluster behavior in different consistency mode?

**URL:** <https://discuss.aerospike.com/t/aerospike-cluster-behavior-in-different-consistency-mode/5541>\
**Category:** Configuration\
**Created:** [September 25, 2018, 9:04pm UTC](https://discuss.aerospike.com/t/aerospike-cluster-behavior-in-different-consistency-mode/5541 "2018-09-25T21:04:10Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![abhijit.chaudhari1](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@abhijit.chaudhari1](https://discuss.aerospike.com/u/abhijit.chaudhari1)\
**Post date:** [September 25, 2018, 9:04pm UTC](https://discuss.aerospike.com/t/aerospike-cluster-behavior-in-different-consistency-mode/5541/1 "2018-09-25T21:04:10Z")

</div>

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 ?

---

<div class="post-metadata">

**Author:** ![meher](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/meher/32/1644_2.png) [@meher](https://discuss.aerospike.com/u/meher)\
**Post date:** [September 25, 2018, 9:05pm UTC](https://discuss.aerospike.com/t/aerospike-cluster-behavior-in-different-consistency-mode/5541/2 "2018-09-25T21:05:11Z")

</div>

[Cross post on stack overflow.](https://stackoverflow.com/questions/52506418/aerospike-cluster-behavior-in-different-consistency-mode)

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.

---

<div class="post-metadata">

**Author:** ![abhijit.chaudhari1](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@abhijit.chaudhari1](https://discuss.aerospike.com/u/abhijit.chaudhari1)\
**Post date:** [September 25, 2018, 9:41pm UTC](https://discuss.aerospike.com/t/aerospike-cluster-behavior-in-different-consistency-mode/5541/3 "2018-09-25T21:41:12Z")

</div>

But this is not the case in AP mode right ?

---

<div class="post-metadata">

**Author:** ![meher](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/meher/32/1644_2.png) [@meher](https://discuss.aerospike.com/u/meher)\
**Post date:** [September 25, 2018, 9:51pm UTC](https://discuss.aerospike.com/t/aerospike-cluster-behavior-in-different-consistency-mode/5541/4 "2018-09-25T21:51:49Z")

</div>

Correct, this is only for strong consistency configured namespaces.

---

<div class="post-metadata">

**Author:** ![abhijit.chaudhari1](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@abhijit.chaudhari1](https://discuss.aerospike.com/u/abhijit.chaudhari1)\
**Post date:** [September 25, 2018, 9:59pm UTC](https://discuss.aerospike.com/t/aerospike-cluster-behavior-in-different-consistency-mode/5541/5 "2018-09-25T21:59:31Z")

</div>

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 ?

---

<div class="post-metadata">

**Author:** ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)\
**Post date:** [September 25, 2018, 10:16pm UTC](https://discuss.aerospike.com/t/aerospike-cluster-behavior-in-different-consistency-mode/5541/6 "2018-09-25T22:16:06Z")

</div>

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`.

---

<div class="post-metadata">

**Author:** ![bbulkow](https://avatars.discourse-cdn.com/v4/letter/b/779978/32.png) [@bbulkow](https://discuss.aerospike.com/u/bbulkow)\
**Post date:** [September 28, 2018, 10:25pm UTC](https://discuss.aerospike.com/t/aerospike-cluster-behavior-in-different-consistency-mode/5541/7 "2018-09-28T22:25:22Z")

</div>

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.