[jira] [Commented] (CASSANDRA-5745) Minor compaction tombstone-removal deadlock

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis commented on CASSANDRA-5745:
-------------------------------------------

bq. if 2 sstables are in the "deadlock" criteria, they will be close in levels and will in fact get compacted relatively quickly in practice, so I'm not sure you can get them to deadlock for long enough that it's a problem in practice

Right, although we have some suboptimal behavior there currently (CASSANDRA-6216).

A pretty simple tweak we could make would be to allow tombstone compactions to include L+1 overlaps.  Then any tombstone-heavy ranges would "bubble up" to the top from L1 and ultimately be squashed.

Just not sure how much extra overhead this introduces in extreme cases like "everything is TTL'd."

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