[jira] [Commented] (CASSANDRA-12166) Sequential repairs on LCS lead to many warnings

["Paulo Motta (JIRA)" <ji...@apache.org>]

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

Paulo Motta commented on CASSANDRA-12166:
-----------------------------------------

bq. I was wondering if this level of verbosity was intended.

This was definitely not intended, and it seems that this fix introduced on CASSANDRA-9935 will make validation slightly slower for sequential repairs, since it will skip the {{LeveledScanner}} optimization where one {{ISSTableScanner}} is used per level, so we will need to rethink that fix.

One solution that comes to mind is that instead of using the leveled manifest to check if an sstable is non-overlapping, we only add an sstable to a given level only if it does not overlap already existing tables in that level.

> Sequential repairs on LCS lead to many warnings
> -----------------------------------------------
>
>                 Key: CASSANDRA-12166
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12166
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Stefano Ortolani
>            Priority: Minor
>              Labels: lcs, lhf
>
> I have been testing sequential repairs on 3.0.8 and now the logs are filled with the following warnings. Note that they do make sense since snapshotting is part of the repair process if sequential, but I was wondering if this level of verbosity was intended.
> {noformat}
> WARN  [ValidationExecutor:3] 2016-07-11 13:35:52,930 LeveledCompactionStrategy.java:231 - Live sstable /data/cassandra/data/schema/cf-e06f37a010bc11e6bb236776bf484396/snapshots/acc9a360-476a-11e6-87e0-dbcbe81a0cea/mb-840-big-Data.db 
> from level 0 is not on corresponding level in the leveled manifest. 
> This is not a problem per se, but may indicate an orphaned sstable due to a failed compaction not cleaned up properly.
> {noformat}



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