[
https://issues.apache.org/jira/browse/CASSANDRA-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13822426#comment-13822426
]
Lyuben Todorov edited comment on CASSANDRA-5351 at 11/14/13 1:37 PM:
---------------------------------------------------------------------
I think I misunderstood Marcus' idea. If we keep all the un-repaired data at L0
and promote it to L1 once repaired, would that mean overriding what currently
happens when there are 10 sstables at L0 (where they get promoted), or is that
where triggering automatic repairs would come in play?
was (Author: lyubent):
I think I misunderstood Marcus' idea. If we keep all the un-repaired data at L0
and promote it to L1 once repaired, would that mind overriding what currently
happens when there are 10 sstables at L0 (where they get promoted), or is that
where triggering automatic repairs would come in play?
> 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
>
>
> 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#6144)
