[
https://issues.apache.org/jira/browse/CASSANDRA-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13705195#comment-13705195
]
Jonathan Ellis commented on CASSANDRA-5745:
-------------------------------------------
One solution occurs to me for LCS: if instead of doing no compactions when
every level is under its quota, we continue pushing data from L1 higher as the
lowest priority task, then our end state would be exactly one sstable per
partition, in the highest level, which implicitly solves this problem.
Alternatively, we could give LCS users a "full compaction" lever, which would
do a one-off compaction of everything into the highest level (still split into
LCS-sized sstables, so it wouldn't be as evil as STCS full compaction).
WDYT [~krummas] [~yukim]?
> 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
