[
https://issues.apache.org/jira/browse/CASSANDRA-9326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14533308#comment-14533308
]
srinivasu gottipati commented on CASSANDRA-9326:
------------------------------------------------
We did run enableAutoCompaction and we are using LCS. Is it that, even though
gc_grace_seconds is passed, still these are not reclaimed due to these deletes
being in higher levels in LCS and compactions didn't happen at those levels?
I see "nodetool compact" runs only for size tiered. Is there any way, to force
compaction to run reclaim this space in LCS case? We are seeing shot up in our
read latencies and any workaround would be greatly appreciated.
> 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)
