[
https://issues.apache.org/jira/browse/CASSANDRA-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161494#comment-14161494
]
Marcus Eriksson commented on CASSANDRA-8004:
--------------------------------------------
[~kohlisankalp] not initially, what I want to avoid here is the really painful
migration to using incremental backups. For the first incremental run, the
repaired leveling will be totally empty and we can move sstables over directly.
The future incremental repairs will do a "can I move this sstable from
unrepaired level X to repaired level X?", and the answer will most often be
"nope", then we drop it to level 0.
It might be a good idea to consider doing in the future (3.0) though. I'm
targeting 2.1 here and want to keep it as simple as possible.
> 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.1
>
>
> 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)
