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. >