[
https://issues.apache.org/jira/browse/CASSANDRA-13818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146145#comment-16146145
]
Blake Eggleston edited comment on CASSANDRA-13818 at 8/29/17 9:19 PM:
----------------------------------------------------------------------
[trunk|https://github.com/bdeggleston/cassandra/tree/13818]
[dtest-branch|https://github.com/bdeggleston/cassandra-dtest/tree/13818]
[utest|https://circleci.com/gh/bdeggleston/cassandra/tree/13818]
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/229/]
Before adding the functionality for this, I did some repair related cleanup.
First, I removed any remaining references to the idea of a 'consistent' repair,
it's all incremental now. I also cleaned up {{RepairRunnable}} a bit. Removing
some unused function args, and refactoring out some abuse
({{List<Pair<Set<InetAddress>, ? extends Collection<Range<Token>>>>}}) of
generics.
I should point out that doing a non-global incremental repair still uses all of
the incremental repair plumbing, it just always demotes the result back to
unrepaired. This means that there is still an anti-compaction performed up
front. This is not optimal from the perspective of moving bytes around on disk,
but I'd rather do that than add another repair path for what should be a repair
option that's not used often. Because of this though, doing a subrange repair
no longer prevents a repair from being considered global. The original reason
for doing this was to prevent anti-compaction, but since anti-compaction is
preformed at the start of an incremental repair, I don't see any reason to just
promote the incrementally repaired subrange when it's finished.
was (Author: bdeggleston):
[trunk|https://github.com/bdeggleston/cassandra/tree/13818]
[dtest|https://github.com/bdeggleston/cassandra-dtest/tree/13818]
[utest|https://circleci.com/gh/bdeggleston/cassandra/tree/13818]
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/229/]
Before adding the functionality for this, I did some repair related cleanup.
First, I removed any remaining references to the idea of a 'consistent' repair,
it's all incremental now. I also cleaned up {{RepairRunnable}} a bit. Removing
some unused function args, and refactoring out some abuse
({{List<Pair<Set<InetAddress>, ? extends Collection<Range<Token>>>>}}) of
generics.
I should point out that doing a non-global incremental repair still uses all of
the incremental repair plumbing, it just always demotes the result back to
unrepaired. This means that there is still an anti-compaction performed up
front. This is not optimal from the perspective of moving bytes around on disk,
but I'd rather do that than add another repair path for what should be a repair
option that's not used often. Because of this though, doing a subrange repair
no longer prevents a repair from being considered global. The original reason
for doing this was to prevent anti-compaction, but since anti-compaction is
preformed at the start of an incremental repair, I don't see any reason to just
promote the incrementally repaired subrange when it's finished.
> Add support for --hosts, --force, and subrange repair to incremental repair
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-13818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13818
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> It should be possible to run incremental repair with nodes down, we just
> shouldn't promote the data to repaired afterwards
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
