[
https://issues.apache.org/jira/browse/CASSANDRA-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14001313#comment-14001313
]
Russell Alexander Spitzer commented on CASSANDRA-6851:
------------------------------------------------------
I began working on this issue (and learning about the compaction paths) by
grouping the repaired and unrepaired tables and then calling a compaction on
each group. This required me to add a hook into AbstractCompactionTask for the
results of a compaction operation so that I could fulfill the return contract
of doAntiCompaction. Currently it seems like the 2.1 tests are not passing
cleanly and I'm not sure of which issues might be related to my patch. I'm
running a bit short on time for this weekend so I'll keep working when I can
find some time.
My major question for finishing this is what should we be using a threshold for
an sstable being to large? Should we let this be user configurable or put a
static ceiling on the compaction?
As usual I would appreciate any advice or critique for my efforts thus far
Current work:
https://github.com/RussellSpitzer/cassandra/compare/CASSANDRA-6851
> Improve anticompaction after incremental repair
> -----------------------------------------------
>
> Key: CASSANDRA-6851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6851
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Marcus Eriksson
> Priority: Minor
> Labels: compaction, lhf
> Fix For: 2.1.1
>
>
> After an incremental repair we iterate over all sstables and split them in
> two parts, one containing the repaired data and one the unrepaired. We could
> in theory double the number of sstables on a node.
> To avoid this we could make anticompaction also do a compaction, for example,
> if we are to anticompact 10 sstables, we could anticompact those to 2.
> Note that we need to avoid creating too big sstables though, if we
> anticompact all sstables on a node it would essentially be a major compaction.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
