From user-return-34744-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Thu Jun 20 09:24:28 2013 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 2B35D10A4A for ; Thu, 20 Jun 2013 09:24:28 +0000 (UTC) Received: (qmail 7829 invoked by uid 500); 20 Jun 2013 09:24:25 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 7809 invoked by uid 500); 20 Jun 2013 09:24:25 -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 7793 invoked by uid 99); 20 Jun 2013 09:24:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Jun 2013 09:24:23 +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; Thu, 20 Jun 2013 09:24:17 +0000 Received: from homiemail-a48.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a48.g.dreamhost.com (Postfix) with ESMTP id 1E05F4F806B for ; Thu, 20 Jun 2013 02:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :content-type:message-id:mime-version:subject:date:references:to :in-reply-to; s=thelastpickle.com; bh=ey9NXiKjSx6NU9ATIqvnwtLWSb I=; b=wUEBPHUsFipTb+XIrdg8CSnUNjproTuRIKVMIrY21ay0/WvVO+nV9C/6cM z6MhnCBt2GCkvj0Gb/xKX7MmqhsPWQ0Frg6FfYYCM6Ats5TAsx9CPWLYNlLm7/d0 4vZxKoNSmtj/emUe8WLiXG1D4XpbBwbeIDVKsij3TKkjNpO/A= Received: from [172.16.1.7] (unknown [203.86.207.101]) (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 650464F805B for ; Thu, 20 Jun 2013 02:23:55 -0700 (PDT) From: aaron morton Content-Type: multipart/alternative; boundary="Apple-Mail=_F8EF5D90-3F5B-4ED2-AF5C-D05710398697" Message-Id: <60137492-5764-4D1D-97FE-8F1C0511776E@thelastpickle.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [Cassandra] Expanding a Cassandra cluster Date: Thu, 20 Jun 2013 21:23:54 +1200 References: <1372322D3525455AA2CEAEC5E159FEB4@gmail.com> <6A747AD830B9440EA4669ACC8072599A@gmail.com> <1370898000.27157.YahooMailNeo@web162005.mail.bf1.yahoo.com> <1371595708.86297.YahooMailNeo@web162005.mail.bf1.yahoo.com> To: Cassandra User In-Reply-To: <1371595708.86297.YahooMailNeo@web162005.mail.bf1.yahoo.com> X-Mailer: Apple Mail (2.1508) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_F8EF5D90-3F5B-4ED2-AF5C-D05710398697 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > 1) Is there any implication in running nodetool repair immediately = after bringing a new node up (before key migration process is completed) = ? > Will it cause some race conditions ? Or will it result in some = part of the space never be reclaimed ? Repair will only be concerned with data that the node is replica for. = And cleanup is only concerned with data that the node is no longer a = replica for.=20 AFAIK they should be able to run concurrently, but I would avoid it = incase there are some edge cases.=20 > 2) How can I figure out the status of key migration in Cassandra? Not sure what you mean by key migration.=20 If you are talking about a token move or node bootstrap you can get some = idea from nodetool compactionstats and nodetool netstats.=20 FWIW I think nodetool cleanup is less aggressive than repair. Repair = reads all the data and creates a hash, cleanup just reads it from one = file and writes a new file dropping rows that no longer belong. It's = probably uses less CPU than compaction as it does not merge row = fragments.=20 Cheers ----------------- Aaron Morton Freelance Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 19/06/2013, at 10:48 AM, Emalayan Vairavanathan = wrote: > Thank you all. >=20 > I have two more question. >=20 > 1) Is there any implication in running nodetool repair immediately = after bringing a new node up (before key migration process is completed) = ? > Will it cause some race conditions ? Or will it result in some = part of the space never be reclaimed ? >=20 > 2) How can I figure out the status of key migration in Cassandra? >=20 > Thank you > Emalayan=20 >=20 > From: Richard Low > To: user@cassandra.apache.org; Emalayan Vairavanathan = =20 > Sent: Tuesday, 18 June 2013 12:11 AM > Subject: Re: [Cassandra] Expanding a Cassandra cluster >=20 > On 10 June 2013 22:00, Emalayan Vairavanathan = wrote: >=20 > b) Will Cassandra automatically take care of = removing obsolete keys in future ? >=20 > In a future version Cassandra should automatically clean up for you: >=20 > https://issues.apache.org/jira/browse/CASSANDRA-5051 >=20 > Right now though you have to run cleanup eventually or the space will = never be reclaimed. >=20 > Richard. >=20 >=20 --Apple-Mail=_F8EF5D90-3F5B-4ED2-AF5C-D05710398697 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
1) Is there any = implication in running nodetool repair immediately after bringing a new = node up (before key migration process is completed) = ?
        Will it cause some race = conditions ? Or will it result in some part of the space never be = reclaimed ?
Repair will only be concerned with = data that the node is replica for. And cleanup is only concerned with = data that the node is no longer a replica for. 
AFAIK they = should be able to run concurrently, but I would avoid it incase there = are some edge cases. 

2) How can I figure out the = status of key migration in Cassandra?
Not sure what = you mean by key migration. 
If you are talking about a = token move or node bootstrap you can get some idea from nodetool = compactionstats and nodetool = netstats. 

FWIW I think nodetool cleanup = is less aggressive than repair. Repair reads all the data and creates a = hash, cleanup just reads it from one file and writes a new file dropping = rows that no longer belong. It's probably uses less CPU than compaction = as it does not merge row = fragments. 

Cheers

=
-----------------
Aaron = Morton
Freelance Cassandra Consultant
New = Zealand

@aaronmorton

On 19/06/2013, at 10:48 AM, Emalayan Vairavanathan <svemalayan@yahoo.com> = wrote:

Thank you = all.

I have two = more question.

1) Is there any implication in = running nodetool repair immediately after bringing a new node up (before = key migration process is completed) ?
        = Will it cause some race conditions ? Or will it result in some part of = the space never be reclaimed ?

2) = How can I figure out the status of key migration in = Cassandra?

Thank you


From: = Richard Low <richard@wentnet.com>
= To: user@cassandra.apache.org; = Emalayan Vairavanathan <svemalayan@yahoo.com>
= Sent: Tuesday, 18 June = 2013 12:11 AM
Subject: Re: [Cassandra] Expanding a Cassandra = cluster

On 10 June 2013 22:00, Emalayan = Vairavanathan <svemalayan@yahoo.com> = wrote:

      =              b) Will Cassandra = automatically take care of removing obsolete keys in future = ?

In a = future version Cassandra should automatically clean up for you:


Right now though you have to run = cleanup eventually or the space will never be reclaimed.

Richard.


=

= --Apple-Mail=_F8EF5D90-3F5B-4ED2-AF5C-D05710398697--