[ https://issues.apache.org/jira/browse/CASSANDRA-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190937#comment-14190937 ]
Aleksey Yeschenko commented on CASSANDRA-8004: ---------------------------------------------- Still looking at it. Other than a failing CrcCheckChanceTest, things mostly look good - or rather as good as we can make them in 2.1, without major internal changes (hopefully we'll be able to redesign the APIs surrounding compaction in 3.x). Need a bit more time to make sure it doesn't break anything else though (incl. 3rd party compaction strategies, in unexpected ways). > Run LCS for both repaired and unrepaired data > --------------------------------------------- > > Key: CASSANDRA-8004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8004 > Project: Cassandra > Issue Type: Bug > Reporter: Marcus Eriksson > Assignee: Marcus Eriksson > Labels: compaction > Fix For: 2.1.2 > > > If a user has leveled compaction configured, we should run that for both the > unrepaired and the repaired data. I think this would make things a lot easier > for end users > It would simplify migration to incremental repairs as well, if a user runs > incremental repair on its nice leveled unrepaired data, we wont need to drop > it all to L0, instead we can just start moving sstables from the unrepaired > leveling straight into the repaired leveling > Idea could be to have two instances of LeveledCompactionStrategy and move > sstables between the instances after an incremental repair run (and let LCS > be totally oblivious to whether it handles repaired or unrepaired data). Same > should probably apply to any compaction strategy, run two instances and > remove all repaired/unrepaired logic from the strategy itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)