incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tupshin Harper <tups...@tupshin.com>
Subject Re: Flushing after dropping a column family
Date Wed, 26 Feb 2014 15:59:41 GMT
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 <0x6e6562@gmail.com> wrote:

> On Wed, Feb 26, 2014 at 3:17 PM, DuyHai Doan <doanduyhai@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.
>

Mime
View raw message