cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremiah Jordan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13225) Best Consistency Level
Date Wed, 15 Feb 2017 23:23:41 GMT

    [ 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)

Mime
View raw message