[
https://issues.apache.org/jira/browse/CASSANDRA-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511724#comment-14511724
]
Yuki Morishita commented on CASSANDRA-9097:
-------------------------------------------
The problem in fixing this in 2.1 is that if we add new repair message, message
deserialization throws Exception in older nodes and it leads to repair hang.
One possible workaround is to poke {{system.peers}} table and check cassandra
version of replica nodes, and skip sending new message during the cluster is in
mixed version.
> 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.5
>
>
> 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)
