[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889716#action_12889716
]
Kelvin Kakugawa commented on CASSANDRA-1072:
--------------------------------------------
The secondary write path is necessary, because we need to make sure that the
total writes to the primary (target) replica are correct. Let's take a
scenario, we have 3 replicas w/ associated counts:
A: [(A, 10)]
B: [(A, 3)]
C: [(A, 5)]
i.e. node A accepted some combination of increments until its count reached 10.
node B was repaired (via read repair or AES) from A's counter value when it
was at 3. node C was repaired when A's count was at 5.
So, if we use the unmodified write path and attempt this write:
[(A, 1)]
i.e. commit a write to node A w/ a delta of 1.
Let's imagine a scenario where the write to node A fails, but the writes to B
and C succeed:
A: [(A, 10)]
B: [(A, 4)]
C: [(A, 6)]
When the counter eventually repairs itself, that write will be considered lost.
Since, the primary replica did not receive that write and the other replicas
were behind. So, the reason why we need to ensure the primary write succeeds,
first, is to ensure that the write has been accounted for in the system. The
secondary writes are just optimistic writes to help the other replicas play
catch-up.
> Increment counters
> ------------------
>
> Key: CASSANDRA-1072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1072
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Johan Oskarsson
> Assignee: Kelvin Kakugawa
> Attachments: CASSANDRA-1072-2.patch, CASSANDRA-1072.patch
>
>
> Break out the increment counters out of CASSANDRA-580. Classes are shared
> between the two features but without the plain version vector code the
> changeset becomes smaller and more manageable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
