[
https://issues.apache.org/jira/browse/CASSANDRA-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13852217#comment-13852217
]
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: https://issues.apache.org/jira/browse/CASSANDRA-5745
> 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
(v6.1.4#6159)
