cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikolai Grigoriev (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8211) Overlapping sstables in L1+
Date Mon, 10 Nov 2014 17:04:35 GMT

    [ 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)

Mime
View raw message