cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lyuben Todorov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5351) Avoid repairing already-repaired data by default
Date Mon, 21 Oct 2013 19:59:52 GMT


Lyuben Todorov commented on CASSANDRA-5351:

The best choice seems like compacting into repaired sstables and unrepaired sstables based
on SSTableMetadata#repairedAt field.

We have two main choices, Repair data going fromg L0 -> L1. Should be reasonable since
repairing at each promotion means we dont need to carry out a lot of repairs during compaction,
but it does mean we need to trigger repairs automatically (I dont like the sound of extra
work before/during compaction), this is why I prefer [~krummas]'s idea of keeping separate
levels of LCS. Next step is to workout how the data at UnrepairedLevelN can jump to RepairedLevelN
without having to go through each level.

> Avoid repairing already-repaired data by default
> ------------------------------------------------
>                 Key: CASSANDRA-5351
>                 URL:
>             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

View raw message