[
https://issues.apache.org/jira/browse/CASSANDRA-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521236#comment-14521236
]
Yuki Morishita commented on CASSANDRA-9097:
-------------------------------------------
Patch available here: https://github.com/yukim/cassandra/tree/9097
(This depends on work in CASSANDRA-9151)
In order to fix this in 2.1, I introduced hack that checks {{release_version}}
of {{system.peers}} table and if it is newer than the version with this fix (I
make it "2.1.6", but it may need to be adjusted before committing), repair
waits for response of anti compaction for upto 1 day(this timeout can be
debatable).
> Repeated incremental nodetool repair results in failed repairs due to running
> anticompaction
> --------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-9097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9097
> Project: Cassandra
> Issue Type: Bug
> Reporter: Gustav Munkby
> Assignee: Yuki Morishita
> Priority: Minor
> Fix For: 2.1.x
>
>
> I'm trying to synchronize incremental repairs over multiple nodes in a
> Cassandra cluster, and it does not seem to easily achievable.
> In principle, the process iterates through the nodes of the cluster and
> performs `nodetool -h $NODE repair --incremental`, but that sometimes fails
> on subsequent nodes. The reason for failing seems to be that the repair
> returns as soon as the repair and the _local_ anticompaction has completed,
> but does not guarantee that remote anticompactions are complete. If I
> subsequently try to issue another repair command, they fail to start (and
> terminate with failure after about one minute). It usually isn't a problem,
> as the local anticompaction typically involves as much (or more) data as the
> remote ones, but sometimes not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
