cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8739) Don't check for overlap with sstables that have had their start positions moved in LCS
Date Wed, 04 Feb 2015 22:43:35 GMT

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

Benedict commented on CASSANDRA-8739:
-------------------------------------

I assume this is another race condition problem, because we shouldn't be able to compact any
files that have had their starts moved? The only way it should be a problem is if we abort,
and then mark compacting based on the starts during the move?

For CASSANDRA-8689 I intend to make it so we only permit markCompacting to succeed on sstables
in the live set. I'm tempted to make it only succeed if the _exact instance_ is the one in
the live set, so that if you're looking at a stale copy of the file (i.e. one with moved starts)
you fail, and reselect your candidates. Would this solve this problem? 

> Don't check for overlap with sstables that have had their start positions moved in LCS
> --------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-8739
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8739
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Marcus Eriksson
>            Assignee: Marcus Eriksson
>             Fix For: 2.1.3
>
>
> When picking compaction candidates in LCS, we check that we won't cause any overlap in
the higher level. Problem is that we compare the files that have had their start positions
moved meaning we can cause overlap. We need to also include the tmplink files when checking
this.
> Note that in 2.1 overlap is not as big problem as earlier, if adding an sstable would
cause overlap, we send it back to L0 instead, meaning we do a bit more compaction but we never
actually have overlap.



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

Mime
View raw message