[
https://issues.apache.org/jira/browse/CASSANDRA-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13705923#comment-13705923
]
Jonathan Ellis commented on CASSANDRA-5745:
-------------------------------------------
bq. Now, if for a sstable that value reaches some threshold (say 30% by
default), then we could check if there is one or more sstable that potentially
could block this gcing (based on the min/max sstable timestamp), and if we find
one (or more), we could force a compaction of those sstables together (for LCS,
we could take the sstable at the smallest level, and compact it to all
overlapping sstable up until the max level sstable
The problem is that you have the 10x magnification per level in LCS, so if you
want to compact "everything that overlaps with one sstable" from L1, you're
compacting ~10% of all your data.
At least with the "big hammer" approach, it only does massive amounts of
compaction when you explicitly ask for it. :)
> 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.1
>
>
> 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 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
