cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "srinivasu gottipati (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9326) Seeing tombstone warning message
Date Thu, 07 May 2015 20:17:00 GMT


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:
>             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 (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

View raw message