You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "srinivasu gottipati (JIRA)" <ji...@apache.org> on 2015/05/07 21:07:00 UTC
[jira] [Resolved] (CASSANDRA-9327) Tombstones are not being cleared
up
[ https://issues.apache.org/jira/browse/CASSANDRA-9327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
srinivasu gottipati resolved CASSANDRA-9327.
--------------------------------------------
Resolution: Duplicate
> Tombstones are not being cleared up
> -----------------------------------
>
> Key: CASSANDRA-9327
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9327
> Project: Cassandra
> Issue Type: Bug
> Reporter: srinivasu gottipati
> Priority: Critical
> Fix For: 2.0.x
>
>
> We deleted part of data from one of column families. After that we ran repair, followed by reducing gc_grace_seconds to have tombstones space to be reclaimed. After this, we kept the compaction enabled to reclaim this space upon passing gc_grace_seconds. We have done this while back and for sure gc_grace_seconds has elapsed.
> Currently, when we run queries against this column family, we are seeing lot of tombstone errors like below:
> WARN [ReadStage:1113] 2015-05-06 17:48:22,556 SliceQueryFilter.java (line 231) Read 19 live and 1140 tombstoned cells in YYY (see tombstone_warn_threshold). 10001 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647}
> The localDeletion reported above is time in future (year:2038, I believe it is the default Integer.MAX_VALUE), and I believe this could be the reason it is not being reclaimed.
> May I know, how do we purge this tombstones and also, what could have set this date to time in future?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)