[
https://issues.apache.org/jira/browse/CASSANDRA-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13890782#comment-13890782
]
Marcus Eriksson commented on CASSANDRA-5351:
--------------------------------------------
Pushed a bunch of changes on top of your commit to
https://github.com/krummas/cassandra/tree/marcuse/5351
Biggest change is the LCS handling which was broken:
Since we run standard LCS when we don't have any repaired data on the node, we
need to move all data from the levels when getting the first repaired sstable.
In order to make this a bit more efficient, we keep the original level in
sstable metadata and hope that we can re-add the sstable at the correct level
once it has been repaired.
> Avoid repairing already-repaired data by default
> ------------------------------------------------
>
> Key: CASSANDRA-5351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5351
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Lyuben Todorov
> Labels: repair
> Fix For: 2.1
>
> Attachments: 5351_node1.log, 5351_node2.log, 5351_node3.log,
> 5351_nodetool.log
>
>
> Repair has always built its merkle tree from all the data in a columnfamily,
> which is guaranteed to work but is inefficient.
> We can improve this by remembering which sstables have already been
> successfully repaired, and only repairing sstables new since the last repair.
> (This automatically makes CASSANDRA-3362 much less of a problem too.)
> The tricky part is, compaction will (if not taught otherwise) mix repaired
> data together with non-repaired. So we should segregate unrepaired sstables
> from the repaired ones.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
