Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 84BA4953D for ; Wed, 1 Feb 2012 08:00:23 +0000 (UTC) Received: (qmail 54436 invoked by uid 500); 1 Feb 2012 08:00:19 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 53505 invoked by uid 500); 1 Feb 2012 08:00:02 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 53364 invoked by uid 99); 1 Feb 2012 07:59:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Feb 2012 07:59:57 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a48.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Feb 2012 07:59:49 +0000 Received: from homiemail-a48.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a48.g.dreamhost.com (Postfix) with ESMTP id 6F3D24F8062 for ; Tue, 31 Jan 2012 23:59:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; q=dns; s=thelastpickle.com; b=0twm+Q8BqV augA4eL0V5E8TpFzPWPzHZRbMdwRE3CijuZLIkPDDpAN0nTzjXJWy1K2VqFsS3cA Q5QbkANaGJ9EGCIetmxrNGpAXw471KggBe1ZDcmw0UNlyaUF9eXioDvne4iYHdkY DYdKCkscFqwDOtICA/IgqlRILptSFe9bw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; s=thelastpickle.com; bh=YO1RIIGdhpdutW5i 4L5zPmjTWZU=; b=A/vGAB0/UIefX/TlYsGbgzliBnIIAyX0ZRzJWtl/S6KYtMYX RnAUkDGytrZ24FcDhrJc3cP4ktQczmYFkaLWmGqDYq1BQq4HWXGAq5e7h0JvYD0U l68KgLMzn6khPN378/8doi+i3B/X1Of5YuzG0S12BugOYnZcDQCJzQe9WuQ= Received: from [172.16.1.3] (125-236-193-159.adsl.xtra.co.nz [125.236.193.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a48.g.dreamhost.com (Postfix) with ESMTPSA id 736F24F805C for ; Tue, 31 Jan 2012 23:59:24 -0800 (PST) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_C72F1CFD-94D1-4E29-8521-2FF24CFC69AD" Subject: Re: Delete doesn't remove row key? Date: Wed, 1 Feb 2012 20:59:19 +1300 In-Reply-To: <4F28963D.3070401@conga.com> To: user@cassandra.apache.org References: <4F288E1E.60508@conga.com> <4F28963D.3070401@conga.com> Message-Id: <9C398250-A5EA-4526-B005-E7EE1D496B0E@thelastpickle.com> X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_C72F1CFD-94D1-4E29-8521-2FF24CFC69AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Second, a followup question: So the row keys will be deleted after 1) = the GC grace period expires, and 2) I do a compaction? Automatic compaction will purge the tombstones.=20 > Third: Assuming the answer is yes, is there any way to manually force = GC of the deleted keys without doing the full "GC shuffle" (setting the = GC grace period artificially low, restarting, compacting, setting grace = period back to normal, restarting)? No. But you do not need to restart. gc_grace_seconds is set per CF and = can be updated without a restart.=20 Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 1/02/2012, at 2:32 PM, Todd Fast wrote: > First, thanks! I'd read that before, but didn't associate doing a = range scan with using the CLI, much less doing "select count(*)" in CQL. = Now I know what to call the phenomenon. >=20 > Second, a followup question: So the row keys will be deleted after 1) = the GC grace period expires, and 2) I do a compaction? >=20 > Third: Assuming the answer is yes, is there any way to manually force = GC of the deleted keys without doing the full "GC shuffle" (setting the = GC grace period artificially low, restarting, compacting, setting grace = period back to normal, restarting)? >=20 > Todd >=20 > On 1/31/2012 5:03 PM, Benjamin Hawkes-Lewis wrote: >> On Wed, Feb 1, 2012 at 12:58 AM, Todd Fast wrote: >>> I added a row with a single column to my 1.0.8 single-node cluster: >>>=20 >>> RowKey: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa >>> =3D> (column=3Dtest, value=3Dhi, timestamp=3D...) >>>=20 >>> I immediately deleted the row using both the CLI and CQL: >>>=20 >>> del Foo[lexicaluuid('aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa')]; >>> delete from Foo using consistency all where >>> KEY=3Daaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa >>>=20 >>> In either case, the column "test" is gone but the empty row key = still >>> remains, and the row count reflects the presence of this phantom = row. >>>=20 >>> I've tried nodetool compact/repair/flush/cleanup/scrub/etc. and = nothing >>> removes the row key. >> http://wiki.apache.org/cassandra/FAQ#range_ghosts >>=20 >> -- >> Benjamin Hawkes-Lewis --Apple-Mail=_C72F1CFD-94D1-4E29-8521-2FF24CFC69AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Second, a followup question: So the row = keys will be deleted after 1) the GC grace period expires, and 2) I do a = compaction?
Automatic compaction will purge the = tombstones. 

Third:= Assuming the answer is yes, is there any way to manually force GC of = the deleted keys without doing the full "GC shuffle" (setting the GC = grace period artificially low, restarting, compacting, setting grace = period back to normal, restarting)?
No. But you do = not need to restart. gc_grace_seconds is set per CF and can be updated = without a = restart. 

Cheers

http://www.thelastpickle.com

On 1/02/2012, at 2:32 PM, Todd Fast wrote:

First, = thanks! I'd read that before, but didn't associate doing a range scan = with using the CLI, much less doing "select count(*)" in CQL. Now I know = what to call the phenomenon.

Second, a followup question: So the = row keys will be deleted after 1) the GC grace period expires, and 2) I = do a compaction?

Third: Assuming the answer is yes, is there any = way to manually force GC of the deleted keys without doing the full "GC = shuffle" (setting the GC grace period artificially low, restarting, = compacting, setting grace period back to normal, = restarting)?

Todd

On 1/31/2012 5:03 PM, Benjamin = Hawkes-Lewis wrote:
On Wed, Feb 1, 2012 at = 12:58 AM, Todd Fast<todd@conga.com> =  wrote:
I added a row with a single column to my 1.0.8 single-node = cluster:

   RowKey: = aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
   =3D> =  (column=3Dtest, value=3Dhi, = timestamp=3D...)

I immediately deleted the row = using both the CLI and CQL:

   del = Foo[lexicaluuid('aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa')];
=
=    delete from Foo using consistency all = where
KEY=3Daaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
<= /blockquote>

In either case, the column = "test" is gone but the empty row key = still
remains, and the row count reflects the presence of this = phantom row.

I've tried nodetool = compact/repair/flush/cleanup/scrub/etc. and = nothing
removes the row = key.
http://wiki.apa= che.org/cassandra/FAQ#range_ghosts

--
Benjamin = Hawkes-Lewis

= --Apple-Mail=_C72F1CFD-94D1-4E29-8521-2FF24CFC69AD--