cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charlie Groves (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5351) Avoid repairing already-repaired data by default
Date Sun, 30 Jun 2013 23:50:20 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696429#comment-13696429
] 

Charlie Groves commented on CASSANDRA-5351:
-------------------------------------------

bq. 3. Do not compact tables which have never been repaired with tables that have had repairs
done. This will prevent new sstables from blowing away the fact that older tables are all
repaired when intersecting ranges per step 2.

What about sstables that share ranges but have different repaired states? They can't be combined
since that would screw up the repaired state one way or the other. Every new sstable written
after starting a repair on the ring will lack some of the repaired ranges from the start of
the repair, so until another complete repair is performed, more and more uncombinable sstables
will accumulate.

I was worried about how this kind of repair would affect compaction in general, for a couple
reasons:

1. sstables being repaired like this would need to be excluded from compaction while the repair
was going on. Otherwise when repair completes, the sstables could have been compacted into
other sstables in the meantime and the repaired ranges couldn't be marked.
2. I think this would also require waiting to mark ranges as repaired until streaming was
ack'd as complete by all the participating nodes. If they were marked as repaired before then
and one of the nodes crashed before the streaming completes, that node would never get the
ranges already marked as repaired.

Those two conditions together mean there'd be a longish window where a significant number
of sstables couldn't be combined. That would degrade read performance while the repair is
going on, and lead to a large compaction when it finishes. I didn't get far enough along to
figure out how large an impact either would have, but that kind of IO variability seemed like
a bad thing to mix in with repair.
                
> 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
>              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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message