cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5745) Minor compaction tombstone-removal deadlock
Date Wed, 18 Dec 2013 18:28:07 GMT

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

Sylvain Lebresne commented on CASSANDRA-5745:
---------------------------------------------

bq. you have a pretty narrow window of "either the result must fit in L, or you must include
all overlaps from L+1."

You're right, forgot about that.

bq.  "first try just dropping tombstones from the sstable by itself, then if that doesn't
get it below the threshold merge it into L+1."

Sounds reasonable. I'll note too that we do estimate for tombstone compaction how many tombstones
won't likely be purgeable due to overlapping other sstables. It's a rough estimate tbh (which
actually makes me wonder how often tombstone compaction do kick in for sstable that are not
on the last level), but if we can improve on that (with minhash maybe?), we could estimate
if it's worth merging with L+1 right away instead of having to compact the sstable alone first.

bq. We're seeing this on STCS as well. Any ideas for how to handle it there?

The "improvement" to the heuristic of tombstone compactions we're talking about should relatively
simply extend to STCS. We focus on LCS mostly because it's actually more complicated there
since you have the constraint that you can't compact any 2 sstables together or you might
break the leveling.

> Minor compaction tombstone-removal deadlock
> -------------------------------------------
>
>                 Key: CASSANDRA-5745
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5745
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Jonathan Ellis
>             Fix For: 2.0.4
>
>
> From a discussion with Axel Liljencrantz,
> If you have two SSTables that have temporally overlapping data, you can get lodged into
a state where a compaction of SSTable A can't drop tombstones because SSTable B contains older
data *and vice versa*. Once that's happened, Cassandra should be wedged into a state where
CASSANDRA-4671 no longer helps with tombstone removal. The only way to break the wedge would
be to perform a compaction containing both SSTable A and SSTable B. 



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Mime
View raw message