[
https://issues.apache.org/jira/browse/CASSANDRA-13225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15868797#comment-15868797
]
Jeremiah Jordan commented on CASSANDRA-13225:
---------------------------------------------
If you app works correctly when this happens and the 3rd node comes up again:
bq. BEST_QUORUM would succeed as 2 replicas are up and would return success
when 2 replicas get the write
Then you should just use QUORUM. You are getting no advantage from
"BEST_QUORUM". Its not like we don't write the data to all 3 nodes when they
are all up.
If what you are worried about is overloading your nodes and want to get all 3
acks back to slow down your writes, then you might want to take a look at using
a back_pressure_strategy.
> Best Consistency Level
> ----------------------
>
> Key: CASSANDRA-13225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13225
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Connor Warrington
> Priority: Minor
>
> When writing data into a cluster there are a few consistency levels to choose
> from. When choosing the consistency level to write with you are making a
> tradeoff between consistency and failover availability. If you choose
> consistency level ALL then all replicas have to be up and when a write
> succeeds all replicas received the write. If you choose consistency level
> QUORUM then a quorum number of replicas have to be up and when a write
> succeeds at quorum number of replicas received the write. The tradeoff comes
> in when there are more then quorum nodes available for the write. We would
> like a write to succeed only when all replicas that are up have received the
> write. Hence the suggestion of best as a consistency level. This would be
> available for the existing consistency levels. The main idea behind this
> feature request is that we are okay with a replica going down (fault
> tolerance) but when the cluster is in a good state we don't mind waiting for
> all nodes to get the write. This would enable the writer to operate at speed
> of the slowest node instead of potentially getting into a state where that
> slow node gets even further behind. This would also enable back pressure to
> be better propagated through the system as the slowest node likely has back
> pressure which is trying to tell the client about but if we don't wait for
> that node the writer loses that information.
> Example scenarios:
> If we have replication factor of 3:
> ALL consistency means 3 replicas have to be up and 3 replicas have to
> successfully get the write.
> QUORUM consistency means 2 replicas have to be up and 2 replicas have to
> successfully get the write.
> BEST_QUORUM consistency means 2 replicas have be up and all up replicas have
> to successfully get the write.
> If 3 replicas are up with replication factor of 3:
> ALL would succeed as all 3 replicas are up and would return success when all
> 3 replicas get the write
> QUORUM would succeed as all 3 replicas are up and would return success when 2
> replicas get the write
> BEST_QUORUM would succeed as all 3 replicas are up and would return success
> when all 3 replicas get the write
> If 2 replicas are up with replication factor of 3:
> ALL would fail as only 2 replicas are up
> QUORUM would succeed as 2 replicas are up and would return success when 2
> replicas get the write
> BEST_QUORUM would succeed as 2 replicas are up and would return success when
> 2 replicas get the write
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
