You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Paulo Motta (JIRA)" <ji...@apache.org> on 2016/08/31 23:40:20 UTC

[jira] [Commented] (CASSANDRA-12489) consecutive repairs of same range always finds 'out of sync' in sane cluster

    [ https://issues.apache.org/jira/browse/CASSANDRA-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453736#comment-15453736 ] 

Paulo Motta commented on CASSANDRA-12489:
-----------------------------------------

It seems this problem is due to the use of combined incremental and subrange repair. One one hand, subrange incremental repair does not mark original sstables as repaired (CASSANDRA-10422), while incremental repair will mark streamed sstables as repaired. So, in the next execution of subrange incremental repair the mismatch will persist. So, we should either:
A) Disable combination of incremental + subrange repair
B) Mark sstables originating from incremental subrange repair as unrepaired

WDYT [~krummas]?

> consecutive repairs of same range always finds 'out of sync' in sane cluster
> ----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-12489
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12489
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Streaming and Messaging
>            Reporter: Benjamin Roth
>         Attachments: trace_3_10.1.log.gz, trace_3_10.2.log.gz, trace_3_10.3.log.gz, trace_3_10.4.log.gz, trace_3_9.1.log.gz, trace_3_9.2.log.gz
>
>
> No matter how often or when I run the same subrange repair, it ALWAYS tells me that some ranges are our of sync. Tested in 3.9 + 3.10 (git trunk of 2016-08-17). The cluster is sane. All nodes are up, cluster is not overloaded.
> I guess this is not a desired behaviour. I'd expect that a repair does what it says and a consecutive repair shouldn't report "out of syncs" any more if the cluster is sane.
> Especially for tables with MVs that puts a lot of pressure during repair as ranges are repaired over and over again.
> See traces of different runs attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)