I've played with it using a 2 nodes cluster with auto_snapshot = false in cassandra.yaml and by deactivating durable write (no commitlog). In my case, truncating tables allows cleaning up data.
With "nodetool status", I can see the data payload decreasing from Gb to some kbytes On Wed, Feb 26, 2014 at 4:59 PM, Tupshin Harper <tups...@tupshin.com> wrote: > This is a known issue that is fixed in 2.1beta1. > https://issues.apache.org/jira/browse/CASSANDRA-5202 > > Until 2.1, we do not recommend relying on the recycling of tables through > drop/create or truncate. > > However, on a single node cluster, I suspect that truncate will work far > more reliably than drop/recreate. > > -Tupshin > > > On Wed, Feb 26, 2014 at 10:53 AM, Ben Hood <0x6e6...@gmail.com> wrote: > >> On Wed, Feb 26, 2014 at 3:17 PM, DuyHai Doan <doanduy...@gmail.com> >> wrote: >> > "I'm noticing that using either TRUNCATE or DROP/CREATE in cqlsh appear >> to >> > leave the underlying data behind." >> > >> > --> What do you mean by "underlying data" ? Are you talking about >> > "snapshots" ? >> >> I was referring to all of the state related to the particular column >> family I want to set fire to, be it snapshots, parts of commit logs, >> sstables, key caches, row caches, or anything else on or off disk that >> relates to said column family. >> >> > If yes, you can wipe them using nodetool clearsnapshots command >> >> This is what I'm doing: >> >> cqlsh:bar> drop table foo; >> >> $ nodetool clearsnapshot bar >> Requested clearing snapshot for: bar >> >> cqlsh:bar> create table foo (....); >> cqlsh:bar> select * from foo limit 1; >> >> This returns nothing (as you would expect). >> >> But this if I re-run this again after about a minute, the data is back. >> >> I get the same behavior if I use nodetool cleanup, flush, compact or >> repair. >> >> It's as if there is either a background app process filling the table >> up again or if the deletion hasn't taken place. >> > >
