I don't want to go down the TTL path because this behaviour is also occurring for tables without a TTL. I don't have hard numbers about the amount of writes, but there's definitely been enough to trigger compaction in the ~year since. We've never changed the topology of this cluster. Ranges have always been the same. I can't remember about repairs, but running sstablemetadata shows Repaired at: 0 across all files. The Cassandra process has been restarted multiple times in the last year. I'v noticed there are only -Data.db and -Index.db files in some rare cases. The compression info, filter, summary, and statistics files are missing. Does that hint at anything?
On Monday, July 31, 2017, 3:39:11 PM PDT, Jeff Jirsa <jji...@apache.org> wrote: On 2017-07-31 15:00 (-0700), kurt greaves <k...@instaclustr.com> wrote: > How long is your ttl and how much data do you write per day (ie, what is > the difference in disk usage over a day)? Did you always TTL? > I'd say it's likely there is live data in those older sstables but you're > not generating enough data to push new data to the highest level before it > expires. > This is a pretty good option. Other options: 1) You changed topology on Nov 28, and the ranges covered by those sstables are no longer intersecting with the ranges on the node, so they're not being selected as LCS compaction candidates (and if you run nodetool cleanup, they probably get deleted) 2) You ran incremental repairs once, and stopped on the 28th, and now those sstables have a repairedAt set, so they won't be compacted with other (unrepaired) sstables 3) There's some horrible bug where the sstables got lost from the running daemon, and if you restart it'll magically get sucked in and start working again (this is really unlikely, and it would be a very bad bug). --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
