Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of maximkr@gmail.com designates
 209.85.161.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:date:from:organization:user-agent:mime-version:to
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        b=cwGfCTQgpB8aqpO+heIM4CWoeZ1KTUz/j4PYlgwP1r8AYC1X0+pH+7p2vsEy7jUTTM
         NiVF/rBBzaNE6HiVbFVvkwyE/3e7PueWfA2dYAaGauULmCmcwuTW/4n7/GWm2nS7jfZu
         on4PXfhFHVis9/+zok+lCzbvWjst/1q58w5k4=
Sender: Maxim Kramarenko <maximkr@gmail.com>
Message-ID: <4C03B5BA.7040601@trackstudio.com>
Date: Mon, 31 May 2010 17:12:26 +0400
From: Maxim Kramarenko <maximkr@trackstudio.com>
Organization: TrackStudio
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.9) Gecko/20100330 Shredder/3.0.4
MIME-Version: 1.0
To: user@cassandra.apache.org
Subject: Re: nodetool cleanup isn't cleaning up?
References: <AANLkTinaxJ1rmBXH4etBBdNJ_OcYdp5zl86F7g9e84No@mail.gmail.com>
 	<4C03ABB9.6050007@trackstudio.com>
 <AANLkTil6FhbmguhjiqgE57ZTpaOr1I09zzHRiAzV7Cn-@mail.gmail.com>
In-Reply-To: <AANLkTil6FhbmguhjiqgE57ZTpaOr1I09zzHRiAzV7Cn-@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello!

I think (but not sure, please correct me if required), that after you 
change token, nodes just receive new data, but don't immediate deletes 
old one. It seems like "clean" will mark them as tombstone and it will 
be deleted when you run "compact" after GCGraceSeconds seconds.

On 31.05.2010 17:00, Ran Tavory wrote:
> Do you think it's the tombstones that take up the disk space?
> Shouldn't the tombstones be moved along with the data?
>
> On Mon, May 31, 2010 at 3:29 PM, Maxim Kramarenko
> <maximkr@trackstudio.com <mailto:maximkr@trackstudio.com>> wrote:
>
>     Hello!
>
>     You likely need wait for GCGraceSeconds seconds or modify this param.
>
>     http://spyced.blogspot.com/2010/02/distributed-deletes-in-cassandra.html
>     ===
>     Thus, a delete operation can't just wipe out all traces of the data
>     being removed immediately: if we did, and a replica did not receive
>     the delete operation, when it becomes available again it will treat
>     the replicas that did receive the delete as having missed a write
>     update, and repair them! So, instead of wiping out data on delete,
>     Cassandra replaces it with a special value called a tombstone. The
>     tombstone can then be propagated to replicas that missed the initial
>     remove request.
>     ...
>     Here, we defined a constant, GCGraceSeconds, and had each node track
>     tombstone age locally. Once it has aged past the constant, it can be
>     GC'd.
>     ===