[
https://issues.apache.org/jira/browse/CASSANDRA-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434267#comment-13434267
]
Nicolas Favre-Felix commented on CASSANDRA-4482:
------------------------------------------------
A node wouldn't have missed A because of a compaction but because A was not
inserted there, since S is not built from the existing data on disk but
incrementally with each change: S really represents the _combined history of
all the changes_ performed on the token range since the last repair session.
So nodes don't have to scan their data to build S, they simply start with S=0
when incremental repair is first enabled regardless of their initial
differences and start again with S=0 after each incremental repair session.
But it is indeed possible for two replicas to have the same data but differing
values for S, for instance if a replica gets A and A' whereas another misses A
but gets A': this would lead to some unnecessary streaming even though they
both have the latest value A'. This could be avoided by removing A from S as
you suggest, but the cost of doing random I/O after each write is too
expensive, as you pointed out earlier.
We are open to suggestions on how to improve this process and get this feature
upstreamed with these issues addressed or understood as inherent limitations.
> In-memory merkle trees for repair
> ---------------------------------
>
> Key: CASSANDRA-4482
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4482
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Marcus Eriksson
>
> this sounds cool, we should reimplement it in the open source cassandra;
> http://www.acunu.com/2/post/2012/07/incremental-repair.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
