[
https://issues.apache.org/jira/browse/CASSANDRA-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191826#comment-14191826
]
Jeremiah Jordan edited comment on CASSANDRA-8004 at 10/31/14 2:13 PM:
----------------------------------------------------------------------
bq. those new methods all have default implementations, and old compaction
strategies should still work, even if they don't track their own sstables -
they get the sstables to compact from cfs and split them in
repaired/unrepaired. We might do it twice per call to 'getNextBackgroundTasks'
though, but that should be fine since we mark the sstables as compacting
Hmm, yeah, I guess it should be fine as long as you are using the same strategy
for repaired and un-repaired it should probably be OK. The issue I see is if
you start doing something like the LCS for repaired STCS for un-repaired. If
STCS wasn't tracking its own sstables, then it would trash everything. But if
you call 3rd party repair twice, then the 2nd call should just decide "nothing
to do" and move on.
was (Author: jjordan):
bq. those new methods all have default implementations, and old compaction
strategies should still work, even if they don't track their own sstables -
they get the sstables to compact from cfs and split them in
repaired/unrepaired. We might do it twice per call to 'getNextBackgroundTasks'
though, but that should be fine since we mark the sstables as compacting
Hmm, yeah, I guess it should be fine as long as you are using the same strategy
for repaired and un-repaired it should probably be OK. The issue I see is if
you start doing something like the LCS for repaired STCS for un-repaired. If
STCS wasn't tracking its own sstables, then it would trash everything. So if
you call 3rd party repair twice, then the 2nd call should just decide "nothing
to do" and move on.
> 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)
