From user-return-24524-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Mon Mar 5 08:58:46 2012 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 68AD49906 for ; Mon, 5 Mar 2012 08:58:46 +0000 (UTC) Received: (qmail 12215 invoked by uid 500); 5 Mar 2012 08:58:44 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 12188 invoked by uid 500); 5 Mar 2012 08:58:44 -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 12172 invoked by uid 99); 5 Mar 2012 08:58:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Mar 2012 08:58:43 +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 (athena.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a93.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Mar 2012 08:58:37 +0000 Received: from homiemail-a93.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a93.g.dreamhost.com (Postfix) with ESMTP id 994748405C for ; Mon, 5 Mar 2012 00:58:16 -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=DHo12ydDlp p+2Lu1aHN3KYTLmYe+xJjgeR07prCg3M7vCqIwNReN+ySvvrUaf5SGDu7cJvVurU w7avOcPlLPM0aZJRS0CqDHUhFeucS9QtP5KChYWFl+OFhznhaSRlcCf7t3KvGqm5 GC3htcV+iVGj14K6zF2HLHmQN4o0fbSAk= 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=4CUwLTp8kfnbQh+j rAZp6UxfSsg=; b=JgPrnWWJN6yBFE0uYxcDWobIHRyYxOl+Cj9vtWHlzJjWJvix HAKsM4/wd1GCc6IptqU4hbO/lAAMFZGrblabTa/36j6Pa9TeYu2ObvVwRxS4asPQ SNiQU3hmLOhniIcEVXNy/SRgsiQk5WvmqbSxF8WCJ/XeikO/DQz2jJ2oV/Y= 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-a93.g.dreamhost.com (Postfix) with ESMTPSA id 0A4BB8405B for ; Mon, 5 Mar 2012 00:58:15 -0800 (PST) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_DC9E48FD-6731-4026-9174-0FB7216D3DB0" Subject: Re: Secondary indexes don't go away after metadata change Date: Mon, 5 Mar 2012 21:58:16 +1300 In-Reply-To: <5D5B7938C0FA6D418BF036797F42AF6818F82976@SOM-EXCH01.nuance.com> To: user@cassandra.apache.org References: <5D5B7938C0FA6D418BF036797F42AF6818F82976@SOM-EXCH01.nuance.com> Message-Id: <55D38831-0861-4229-87A3-08982C078B8D@thelastpickle.com> X-Mailer: Apple Mail (2.1257) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_DC9E48FD-6731-4026-9174-0FB7216D3DB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The secondary index CF's are marked as no longer required / marked as = compacted. under 1.x they would then be deleted reasonably quickly, and = definitely deleted after a restart.=20 Is there a zero length .Compacted file there ?=20 > Also, when adding a new node to the ring the new node will build = indexes for the ones that supposedly don=92t exist any longer. Is this = supposed to happen? Would this have happened if I had deleted the old = SSTables from the previously existing nodes? Check you have a consistent schema using describe cluster in the CLI. = And check the schema is what you think it is using show schema.=20 Another trick is to do a snapshot. Only the files in use are included = the snapshot.=20 Hope that helps.=20 =20 ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 2/03/2012, at 2:53 AM, Frisch, Michael wrote: > I have a few column families that I decided to get rid of the = secondary indexes on. I see that there aren=92t any new index SSTables = being created, but all of the old ones remain (some from as far back as = September). Is it safe to just delete then when the node is offline? = Should I run clean-up or scrub? > =20 > Also, when adding a new node to the ring the new node will build = indexes for the ones that supposedly don=92t exist any longer. Is this = supposed to happen? Would this have happened if I had deleted the old = SSTables from the previously existing nodes? > =20 > The nodes in question have either been upgraded from v0.8.1 =3D> = v1.0.2 (scrubbed at this time) =3D> v1.0.6 or from v1.0.2 =3D> v1.0.6. = The secondary index was dropped when the nodes were version 1.0.6. The = new node added was also 1.0.6. > =20 > - Mike --Apple-Mail=_DC9E48FD-6731-4026-9174-0FB7216D3DB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The secondary index CF's are marked as no longer = required / marked as compacted. under 1.x they would then be deleted = reasonably quickly, and definitely deleted after a = restart. 

Is there a zero length .Compacted file = there ? 

Also, when adding a new node = to the ring the new node will build indexes for the ones that supposedly = don=92t exist any longer.  Is this supposed to happen?  Would = this have happened if I had deleted the old SSTables from the previously = existing = nodes?
Check you = have a consistent schema using describe cluster in the CLI. And check = the schema is what you think it is using show = schema. 

Another trick is to do a = snapshot. Only the files in use are included the = snapshot. 

Hope that = helps. 
 
http://www.thelastpickle.com

On 2/03/2012, at 2:53 AM, Frisch, Michael wrote:

I have a few column families = that I decided to get rid of the secondary indexes on.  I see that = there aren=92t any new index SSTables being created, but all of the old = ones remain (some from as far back as September).  Is it safe to = just delete then when the node is offline?  Should I run clean-up = or scrub?
 
Also, when adding a new node to the ring the new node will = build indexes for the ones that supposedly don=92t exist any = longer.  Is this supposed to happen?  Would this have happened = if I had deleted the old SSTables from the previously existing = nodes?
 
The nodes in = question have either been upgraded from v0.8.1 =3D> v1.0.2 (scrubbed = at this time) =3D> v1.0.6 or from v1.0.2 =3D> v1.0.6.  The = secondary index was dropped when the nodes were version 1.0.6.  The = new node added was also 1.0.6.
- = Mike

= --Apple-Mail=_DC9E48FD-6731-4026-9174-0FB7216D3DB0--