[ https://issues.apache.org/jira/browse/CASSANDRA-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15726936#comment-15726936 ]
Jeff Jirsa commented on CASSANDRA-13005: ---------------------------------------- I'm unsure how you're suddenly missing components. However, a lot of factors go into what can/cant be safely deleted. One of the most common reasons TWCS doesn't drop a fully expired table is overlapping files. There exists a tool - sstableexpiredblockers - meant to help diagnose such a problem. Are you able to run it on that table? > 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 > 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)