[
https://issues.apache.org/jira/browse/CASSANDRA-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14981297#comment-14981297
]
Ariel Weisberg edited comment on CASSANDRA-10422 at 10/29/15 9:24 PM:
----------------------------------------------------------------------
[~krummas] do we do incremental repair + subrange repair outside of that path
via nodetool?
I am not following why additional work is necessary if there is no path to
start this problematic repair combination? The isIncremental flag is propagated
to the other nodes, and that is what drives anti-compaction on other nodes
right? So if we don't allow a repair to start with the combination of
incremental and subrange there shouldn't be an issue.
When you say full repair what do you mean? Not a repair of a subrange? I
thought that is the situation where we want to anti-compact.
was (Author: aweisberg):
--[~krummas] do we do incremental repair + subrange repair outside of that path
via nodetool?--
--I am not following why additional work is necessary if there is no path to
start this problematic repair combination? When you say full repair what do you
mean? Not a repair of a subrange? I thought that is the situation where we want
to anti-compact.--
Nevermind figured out what you are talking about.
> Avoid anticompaction when doing subrange repair
> -----------------------------------------------
>
> Key: CASSANDRA-10422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10422
> Project: Cassandra
> Issue Type: Bug
> Reporter: Marcus Eriksson
> Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> If we do split the owned range in say 1000 parts, and then do one repair
> each, we could potentially anticompact every sstable 1000 times (ie, we
> anticompact the repaired range out 1000 times). We should avoid
> anticompacting at all in these cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
