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 D74B37457 for ; Wed, 21 Dec 2011 21:10:48 +0000 (UTC) Received: (qmail 22307 invoked by uid 500); 21 Dec 2011 21:10:46 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 22278 invoked by uid 500); 21 Dec 2011 21:10:46 -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 22270 invoked by uid 99); 21 Dec 2011 21:10:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Dec 2011 21:10:46 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a53.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Dec 2011 21:10:41 +0000 Received: from homiemail-a53.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a53.g.dreamhost.com (Postfix) with ESMTP id 4C565138059 for ; Wed, 21 Dec 2011 13:10:19 -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=bMVNaGuh4W PspcqWdiw3Cemg6YTtFX2adYB55Q+ZjlT98Nt9NdJkzgByH2sgFwnHxOCkAycAXD Q17plsnLk674hbwDXNkrFhBiec6RCnBqNhIzRe5NOxSHF4oexCp+I0AmfClv29zB VsaE+wR6Pshh0viUEStr8BvSRKgReLN74= 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=wuvqnbmjyymVPZID Bd5ZRx8+b0Q=; b=uML7SdLAX3jBtCViVqB4zGe9mVdCVebdPG/mYHVMpm5Bx0Rk JewN626jYHfQJNiS0BoLCTQJC8VDb4bR0d0UGOb7BVucqzfp4TpFuoeLd0tvnM3Q 1ZvpXSAk0gqdiqAEzSktHq2+jRhLoAGn06K246ZF/3Toq75qxqIAi7xLzi8= Received: from [172.16.1.4] (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-a53.g.dreamhost.com (Postfix) with ESMTPSA id 92426138056 for ; Wed, 21 Dec 2011 13:10:18 -0800 (PST) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_6C13E91C-16D5-411A-AB35-54B2C9B30085" Subject: Re: Handling topology changes Date: Thu, 22 Dec 2011 10:10:14 +1300 In-Reply-To: <20111221113448.GA26219@omega> To: user@cassandra.apache.org References: <20111221113448.GA26219@omega> Message-Id: <7FA604EE-4FC9-4F45-80B5-028A71D5CA06@thelastpickle.com> X-Mailer: Apple Mail (2.1251.1) --Apple-Mail=_6C13E91C-16D5-411A-AB35-54B2C9B30085 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii How often is "relatively often" ?=20 > * having a fixed amount of nodes with initial tokens and letting new > ones auto bootstrap themselves Generally a bad idea, you should make sure nodes re given sensible = tokens that evenly distribute the data.=20 Cheers =20 ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 22/12/2011, at 12:34 AM, pyr@smallrivers.com wrote: > Hi, >=20 > I wonder about the best strategy when a cluster sees changes in its > topology relatively often. >=20 > My main concern is how to handle the initial token for new nodes. If a > cluster is first created with 7 nodes for which the initial token is > calculated with the formula here: > http://wiki.apache.org/cassandra/Operations#Token_selection. >=20 > It seems as though two strategies can be applied: >=20 > * having a fixed amount of nodes with initial tokens and letting new > ones auto bootstrap themselves > * recomputing tokens for the new number of nodes and using nodetool = move > for each of those >=20 > Is any of these right and are there other strategies ? >=20 > - pyr --Apple-Mail=_6C13E91C-16D5-411A-AB35-54B2C9B30085 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii How = often is "relatively often" ? 

* having a fixed amount of nodes with initial tokens = and letting new
 ones auto bootstrap = themselves
Generally a bad idea, you should make sure = nodes re given sensible tokens that evenly distribute the = data. 

Cheers

 = ;
http://www.thelastpickle.com

On 22/12/2011, at 12:34 AM, pyr@smallrivers.com = wrote:

Hi,

I wonder about the best strategy when a = cluster sees changes in its
topology relatively often.

My main = concern is how to handle the initial token for new nodes. If = a
cluster is first created with 7 nodes for which the initial token = is
calculated with the formula here:
http:= //wiki.apache.org/cassandra/Operations#Token_selection.

It = seems as though two strategies can be applied:

* having a fixed = amount of nodes with initial tokens and letting new
 ones auto = bootstrap themselves
* recomputing tokens for the new number of nodes = and using nodetool move
 for each of those

Is any of = these right and are there other strategies ?

  - = pyr

= --Apple-Mail=_6C13E91C-16D5-411A-AB35-54B2C9B30085--