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/07/25 16:06:00 UTC

[jira] [Created] (CASSANDRA-14593) Read-Repair breaks partition-level update atomicity

Benedict created CASSANDRA-14593:
------------------------------------

             Summary: Read-Repair breaks partition-level update atomicity
                 Key: CASSANDRA-14593
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14593
             Project: Cassandra
          Issue Type: Bug
            Reporter: Benedict


We advertise generally that updates apply atomically within a partition, and users depend on the fact that visibility is guaranteed to coincide, i.e. that two rows updated at once will only be seen together.
 
However, a read that only touches one of these rows can lead to a quorum of nodes having only part of the update.
 
For instance, let’s take either a write at CL.ONE, or a failed write at QUORUM, that updates two rows.  The write makes it to only one node.  A read is performed that only touches one of these rows, and happens to include the node that received the write so read-repair is engaged.  Now, all nodes are updated to contain this row touched by the read-repair.
 
A new QUORUM read is performed covering both rows, and the node that received the whole update is not queried.  Now only the first row is returned.
 
Any application depending on both rows being visible together, for any query that requests them, will now be in an indeterminate state.
 
This seems like a fairly dangerous contractual failure, and one we should explicitly document, and we should permit disabling read-repair entirely for users who need it.
 
Or, perhaps preferably, we could modify read-repair to perform a whole-partition repair, that is only triggered by the detection of inconsistency (rather than being directly driven by the requested data).



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