You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benedict (JIRA)" <ji...@apache.org> on 2018/09/20 15:40:00 UTC
[jira] [Updated] (CASSANDRA-14769) Batchlog consistency
proportional to live nodes, not DC size
[ https://issues.apache.org/jira/browse/CASSANDRA-14769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benedict updated CASSANDRA-14769:
---------------------------------
Summary: Batchlog consistency proportional to live nodes, not DC size (was: Batchlog consistency requirements proportional to live nodes, not DC size)
> Batchlog consistency proportional to live nodes, not DC size
> ------------------------------------------------------------
>
> Key: CASSANDRA-14769
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14769
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
> Reporter: Benedict
> Priority: Major
>
> Batchlog tries to write to at least two nodes in the DC, if there are two or more nodes in the DC. But if all other nodes are down, it will accept writing with just CL.ONE. This doesn’t *seem* to be intentional, and I think we should probably fail the batch log write in this scenario.
> The prior discussion I could find on this topic was in CASSANDRA-9895, wherein the following was stated:
> bq. The idea was that the batchlog should give you the guarantee that you won't lose atomicity unless you lose 3 machines during the request (coordinator plus two others)
> If this is the intended guarantee, depending on liveness to decide your consistency seems busted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org