[
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
