[
https://issues.apache.org/jira/browse/CASSANDRA-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13705891#comment-13705891
]
Sylvain Lebresne commented on CASSANDRA-5745:
---------------------------------------------
For what it's worth I'm pretty sure that the "problem" described in the
description of this ticket is a non issue in practice or at least very (very)
rarely an issue (happy to develop on that if needed).
But if we are really afraid of it (which as said above I'm not really), I think
another less "big-hammer" and more automatic solution would be to add one more
compaction heuristic like we already have the "try compacting a sstable if it's
has more than X% gcable stuffs and you have nothing better to do".
Namely, we store enough information that for a sstable we can estimate "how
much stuff where gcable in the last compaction but didn't got removed" (we have
histograms of the local deletion time and we know when was the last compaction,
so it's just the amount of stuff whose deletion time is before that last
compaction). 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; or if we want
something simpler we could just compact thoses sstables back into L1 directly
(or even L0 if we're really lazy)).
That being said, if we really want to write down a "major compaction"
implementation for LCS to have it in our toolbelt (but whose use would be
discouraged unless you have good reason to think that it might help you), then
I'm fine with that. Though part of me thinks we should probably avoid 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
