[ 
https://issues.apache.org/jira/browse/CASSANDRA-14768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedict updated CASSANDRA-14768:
---------------------------------
    Component/s:     (was: Legacy/Coordination)
                 Consistency/Batch Log

> Transient Replication: Consistency Level Semantics
> --------------------------------------------------
>
>                 Key: CASSANDRA-14768
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14768
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Consistency/Batch Log
>            Reporter: Benedict
>            Priority: Major
>             Fix For: 4.0
>
>
> For a keyspace without transient replication, we will always attempt (and 
> write hints for) all logical endpoints, including those that seem to be alive 
> but are not responding (or perhaps dropping some messages).  With transient 
> replication, in this scenario we only write to the transient replicas if a 
> certain period of time elapses _and we have not met our consistency level_.
> This doesn’t lead to the same logical behaviour, although technically the 
> guarantees are the same.  In the past, you could expect that all DCs would 
> reach their own local quorum promptly, if say only a single node is failing.  
> Now, you could reach QUORUM with only one DC + 1 remote node, and the remote 
> DC will stay out of whack until repair runs.  This is even worse for e.g. 
> LOCAL_\{QUORUM,ONE\}.
> While the guarantees of the system are the same, the actual behaviour is 
> suboptimal - while the coordinator and remote DCs are healthy, in my opinion 
> we should do our best to ensure each DC reaches its own quorum, just as a 
> normal write would.
> This probably entails having our write callback handle failure to not only 
> write a hint for the endpoint, but also decide if a mutation should 
> immediately be sent to a corresponding transient replica.
> At the very least, we should discuss this before 4.0, even if we opt to take 
> no action before 4.x.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to