cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5745) Minor compaction tombstone-removal deadlock
Date Tue, 17 Dec 2013 20:48:08 GMT


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

> Minor compaction tombstone-removal deadlock
> -------------------------------------------
>                 Key: CASSANDRA-5745
>                 URL:
>             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

View raw message