[
https://issues.apache.org/jira/browse/CASSANDRA-9326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14555586#comment-14555586
]
srinivasu gottipati commented on CASSANDRA-9326:
------------------------------------------------
We are stuck with this issue, I checked Cassandra-7272 and it is fixed in
2.2.0x, also don't see sstablelevelreset not available in 2.0.14.
Scrub/repairs didn't help us and we are in LCS.
May I know, is there workaround to clear up this tombstones in 2.0.14 (Like
adjusting sstable sizes (or) using unchecked_tombstone_compaction, any other
recommendations)?
I really appreciate your help on this.
> Seeing tombstone warning message
> --------------------------------
>
> Key: CASSANDRA-9326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9326
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: srinivasu gottipati
> Priority: Minor
> Fix For: 2.0.x
>
>
> We deleted data for some of the rows in one of the column families.
> After that we ran repair on all nodes, and followed by reducing
> gc_grace_seconds that way compaction can remove all the tombstones upon
> expiry of gc_grace_seconds time.
> When we are querying the data now, seeing the following errors:
> WARN [ReadStage:1142] 2015-05-06 17:50:53,602 SliceQueryFilter.java (line
> 231) Read 1 live and 1487 tombstoned cells in XXXX (see
> tombstone_warn_threshold). 10001 columns was requested, slices=[-],
> delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647}
> We deleted this data while back and for sure gc_grace_seconds is elapsed long
> time back and we use leveled compaction. In the above, errors, localDeletion
> points to some time in future (MAX INT VALUE) and that could be the reason
> these are n't being purged. Any help (or) workaround is appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
