Drop CF takes a snapshot of the CF first, and then marks SSTables on disk as
compacted so they will be safely deleted later. Finally it removes the CF from
the meta data.
If you see the SSTables on disk, you should see 0 length .compacted files for
every one of them.
Cheers
Does drop work in a similar way?
When I drop a CF and add it back with a different schema, it seems to work.
But I notice that in between the drop and adding it back, when the CLI
tells me the CF doesn't exist, the old data is still there.
I've been assuming that this works, but just wanted to m
Each node (independently) has logic that guarantees that any writes
processed before the truncate, will be wiped out.
This does not mean that each node will wipe out the same data, or even
that each node will process the truncate (which would result in a
timedoutexception).
It also does not mean
If those went to zero, it would certainly tell me something happened. :) I
guess watching that would be a way of seeing something was going on.
Is the truncate itself propagating a ring-wide marker or anything so the CF
is logically "empty" before being physically removed? That's the impression
There's a JMX method to get the number of sstables in a CF, is that
what you're looking for?
On Mon, Jun 27, 2011 at 1:04 PM, Ethan Rowe wrote:
> Is there any straightforward means of seeing what's going on after issuing a
> truncate (on 0.7.5)? I'm not seeing evidence that anything actually
> h
Is there any straightforward means of seeing what's going on after issuing a
truncate (on 0.7.5)? I'm not seeing evidence that anything actually
happened. I've disabled read repair on the column family in question and
don't have anything actively reading/writing at present, apart from my
one-off
