cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-5907) Leveled compaction may cause overlap in L1 when L0 compaction get behind
Date Tue, 20 Aug 2013 23:09:52 GMT

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

Jonathan Ellis edited comment on CASSANDRA-5907 at 8/20/13 11:08 PM:
---------------------------------------------------------------------

It looks like the problem then is a race when we are running getCandidatesFor before a parallel
compaction has marked its sources compacting.  We synchronize getCompactionCandidates (caller
of getCandidatesFor) but that is not adequate.

(Edit: which would mean that it can indeed happen with any number of candidates, in theory.)
                
      was (Author: jbellis):
    It looks like the problem then is a race when we are running getCandidatesFor before a
parallel compaction has marked its sources compacting.  We synchronize getCompactionCandidates
(caller of getCandidatesFor) but that is not adequate.
                  
> Leveled compaction may cause overlap in L1 when L0 compaction get behind
> ------------------------------------------------------------------------
>
>                 Key: CASSANDRA-5907
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5907
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Yuki Morishita
>            Assignee: Yuki Morishita
>            Priority: Minor
>             Fix For: 1.2.9
>
>
> 1.2 makes LCS run parallel, though if L0 compaction get far behind and concurrent compactions
at L0 where each compaction holds maximum number of SSTable to compact at L0(32), it will
likely cause overlap in L1. There will be ERROR log as follows:
> {code}
> ERROR [CompactionExecutor:30] 2013-08-19 17:54:29,648 LeveledManifest.java (line 244)
At level 1, SSTableReader(path='xxx-Data.db') [DecoratedKey(204853724659241194183955214890519,
30303132343830), DecoratedKey(69227335985728660912035125310473966323, 30393537373332)] overlaps
SSTableReader(path='xxx-Data.db') [DecoratedKey(217896711032704014921095870827202, 30333635363932),
DecoratedKey(71430242198281555888954138354238066233, 30333035343132)].  This is caused by
a bug in Cassandra 1.1.0 .. 1.1.3.  Sending back to L0.  If you have not yet run scrub, you
should do so since you may also have rows out-of-order within an sstable
> {code}
> We should send back compacted SSTables to L0 when compacting max SSTables at L0. Also,
the above error message is confusing, at version 1.2, we can reduce to WARNing level without
mentioning scrub.
> C* 2.0 performs Size-Tiered compaction on L0 when it has max SSTables and sends back
compacted SSTable to L0, so I think we don't need to fix this on 2.0.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message