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)