[
https://issues.apache.org/jira/browse/CASSANDRA-8211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204994#comment-14204994
]
Nikolai Grigoriev commented on CASSANDRA-8211:
----------------------------------------------
Could it happen at any level? I did use sstablesplit in my cluster and I have
recently spotted a number of messages like:
{code}
system.log.1: WARN [main] 2014-11-09 03:32:17,434 LeveledManifest.java (line
164) At level 1,
SSTableReader(path='/cassandra-data/disk2/myks/mytable1/myks-mytable1-jb-200217-Data.db')
[DecoratedKey(-1632759770741703333,
001000000000111100000000000001164335000010000000000116433500000000111100000000100000000000004000000000000000000100),
DecoratedKey(2116162112767472431,
001000000000111100000000000001432a4c0000100000000001432a4c00000000111100000000100000000000004000000000000000000100)]
overlaps
SSTableReader(path='/cassandra-data/disk3/myks/mytable1/myks-mytable1-jb-200215-Data.db')
[DecoratedKey(665029536263181199,
0010000000001111000000000000052d6e8d00001000000000052d6e8d00000000111100000000100000000000004000000000000000000100),
DecoratedKey(1008355148187355376,
001000000000111100000000000001135f970000100000000001135f9700000000111100000000100000000000004000000000000000000100)].
This could be caused by a bug in Cassandra 1.1.0 .. 1.1.3 or due to the fact
that you have dropped sstables from another node into the data directory.
Sending back to L0. If you didn’t drop in sstables, and have not yet run
scrub, you should do so since you may also have rows out-of-order within an
sstable
{code}
> Overlapping sstables in L1+
> ---------------------------
>
> Key: CASSANDRA-8211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8211
> Project: Cassandra
> Issue Type: Bug
> Reporter: Marcus Eriksson
> Assignee: Marcus Eriksson
> Fix For: 2.0.12
>
> Attachments: 0001-Avoid-overlaps-in-L1-v2.patch,
> 0001-Avoid-overlaps-in-L1.patch
>
>
> Seems we have a bug that can create overlapping sstables in L1:
> {code}
> WARN [main] 2014-10-28 04:09:42,295 LeveledManifest.java (line 164) At level
> 2, SSTableReader(path='<sstable>') [DecoratedKey(2838397575996053472, 00
> 10000000001111000000000000066059b200001000000000066059b200000000111100000000100000000000004000000000000000000100),
> DecoratedKey(5516674013223138308,
> 001000000000111100000000000000ff2d160000100000000000ff2d1600000
> 000111100000000100000000000004000000000000000000100)] overlaps
> SSTableReader(path='<sstable>') [DecoratedKey(2839992722300822584,
> 00100000000011110000
> 0000000000229ad20000100000000000229ad200000000111100000000100000000000004000000000000000000100),
> DecoratedKey(5532836928694021724,
> 0010000000001111000000000000034b05a600001000000000034b05a600000000111100000000100
> 000000000004000000000000000000100)]. This could be caused by a bug in
> Cassandra 1.1.0 .. 1.1.3 or due to the fact that you have dropped sstables
> from another node into the data directory. Sending back to L0. If
> you didn't drop in sstables, and have not yet run scrub, you should do so
> since you may also have rows out-of-order within an sstable
> {code}
> Which might manifest itself during compaction with this exception:
> {code}
> ERROR [CompactionExecutor:3152] 2014-10-28 00:24:06,134 CassandraDaemon.java
> (line 199) Exception in thread Thread[CompactionExecutor:3152,1,main]
> java.lang.RuntimeException: Last written key
> DecoratedKey(5516674013223138308,
> 001000000000111100000000000000ff2d160000100000000000ff2d1600000000111100000000100000000000004000000000000000000100)
> >= current key DecoratedKey(2839992722300822584,
> 001000000000111100000000000000229ad20000100000000000229ad200000000111100000000100000000000004000000000000000000100)
> writing into <sstable>
> {code}
> since we use LeveledScanner when compacting (the backing sstable scanner
> might go beyond the start of the next sstable scanner)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
