cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Esken (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13005) Cassandra TWCS is not removing fully expired tables
Date Thu, 08 Dec 2016 10:55:58 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15731840#comment-15731840
] 

Christian Esken commented on CASSANDRA-13005:
---------------------------------------------

I did not run sstableexpiredblockers on the day of the problem, as the production database
has been quickly recreated. I might be able to place a couple of the defective SSTable files
in a test installation instead. That might take some time, though. In general, I would expect
that overlaps would be assumed, as max local deletion time is MAX_INT (2147483647), according
to the attached sstablemetadata:

Minimum timestamp: -9223372036854775808
Maximum timestamp: 9223372036854775807
SSTable min local deletion time: 2147483647
SSTable max local deletion time: 2147483647


> Cassandra TWCS is not removing fully expired tables
> ---------------------------------------------------
>
>                 Key: CASSANDRA-13005
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13005
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Compaction
>         Environment: Cassandra 3.0.9
> Java HotSpot(TM) 64-Bit Server VM version 25.112-b15 (Java version 1.8.0_112-b15)
> Linux 3.16
>            Reporter: Christian Esken
>              Labels: twcs
>         Attachments: sstablemetadata-empty-type-that-is-3GB.txt
>
>
> I have a table where all columns are stored with TTL of maximum 4 hours. Usually TWCS
compaction properly removes  expired data via tombstone compaction and also removes fully
expired tables. The number of SSTables is nearly constant since weeks. Good.
> The problem:  Suddenly TWCS does not remove old SSTables any longer. They are being recreated
frequently (judging form the file creation timestamp), but the number of tables is growing.
Analysis and actions take so far:
> - sstablemetadata shows strange data, as if the table is completely empty.
> - sstabledump throws an Exception when running it on such a SSTable
> - Even triggering a manual major compaction will not remove the old SSTable's. To be
more precise: They are recreated with new id and timestamp (not sure whether they are identical
as I cannot inspect content due to the sstabledump crash)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message