[
https://issues.apache.org/jira/browse/CASSANDRA-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724650#action_12724650
]
Jun Rao commented on CASSANDRA-225:
-----------------------------------
I felt that we didn't give this one enough thought. The 2 criticisms of sending
writes to a master node and let it propagate the writes to the secondaries are
the following:
1. This reduces availability on master node failure.
2. The implementation can be complicated.
For 1, we really have to factor in the time for failure detection. If it takes
5 seconds to deect a node failure and re-electing a master takes only 1 second,
the availability from the client's perspective is not reduced much.
For 2, it is true that the implementation of mastered writes is more
complicated than sending writes independently to all nodes. On the other hand,
this makes it possible to efficiently sync up the replicas by just shipping
portions of the commit logs. By relying on this single mechanism to resolve
data inconsistency, we can get rid of passive read repair (which consumes
resources on every read), hinted handoff, and the active repair that we are
working on. Overall, the code complexity could be reduced.
I see a couple of other benefits of mastered writes.
a. This makes the handling of deletes easier. By synchronizing the logs among
replicas, we can be sure when a tombstone can be safely discarded. This is
better than our current approach that relies on a configured window. See the
"handling deletes" thread we had earlier
(http://mail-archives.apache.org/mod_mbox/incubator-cassandra-dev/200904.mbox/browser).
b. This makes it possible for a replica to reason about how out of date it is
and therefore provides some sort of timeline consistency.
> Support mastered writes
> -----------------------
>
> Key: CASSANDRA-225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-225
> Project: Cassandra
> Issue Type: New Feature
> Affects Versions: 0.4
> Environment: all
> Reporter: Sandeep Tata
> Assignee: Sandeep Tata
> Attachments: 225.patch
>
>
> Writes to a row today can be run on any of the replicas that own the row. An
> additional set of APIs to perform "mastered" writes that funnel through a
> primary is important if applications have some operations that require higher
> consistency. Test-and-set is an example of one such operation that requires a
> higher consistency guarantee.
> To stay true to Cassandra's performance goals, this should be done in a way
> that does not compromise performance for apps that can deal with lower
> consistency and never use these APIs. That said, an app that mixes higher
> consistency calls with lower consistency calls should be careful that they
> don't operate on the same data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
