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