cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Bailey (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5745) Minor compaction tombstone-removal deadlock
Date Wed, 18 Dec 2013 22:05:07 GMT


Nick Bailey commented on CASSANDRA-5745:

I've noticed it with OpsCenter's metrics column families. Specifically in this case on a 2
node cluster, where 1 node has not seen the issue and another has.

It seems like it could be fairly common in data models where data is only removed by TTL.
I'm guessing that in this case a repair caused overlap between two sstables and now we are
in a situation where we have an sstable large enough to be in its own bucket when doing minor
compactions that is entirely tombstones, but won't get deleted by tombstone compaction due
to this.

> Minor compaction tombstone-removal deadlock
> -------------------------------------------
>                 Key: CASSANDRA-5745
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Priority: Minor
>             Fix For: 3.0
> 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