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 EFCF27AE3 for ; Wed, 21 Dec 2011 11:36:16 +0000 (UTC) Received: (qmail 62756 invoked by uid 500); 21 Dec 2011 11:36:14 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 62648 invoked by uid 500); 21 Dec 2011 11:36:14 -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 62640 invoked by uid 99); 21 Dec 2011 11:36:14 -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 11:36:14 +0000 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= X-Spam-Check-By: apache.org Received-SPF: unknown (athena.apache.org: error in processing during lookup of pyr@smallrivers.com) Received: from [208.89.132.141] (HELO outbound001.roc2.bluetie.com) (208.89.132.141) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Dec 2011 11:36:07 +0000 Received: from emta003.roc2.bluetie.com ([10.200.2.133]) by outbound001.roc2.bluetie.com with bizsmtp id Bnbl1i0042sBFZW01nblD4; Wed, 21 Dec 2011 06:35:45 -0500 X-CMAE-OUT-Analysis: v=2.0 cv=AdYz7grG c=1 sm=1 a=g9t9ilS78gmBpuR3CmqkWw==:17 a=wom5GMh1gUkA:10 a=UGYSPidUAR0A:10 a=wPDyFdB5xvgA:10 a=kj9zAlcOel0A:10 a=mV9VRH-2AAAA:8 a=Jw4AdOw4kw8Y_plY5YIA:9 a=CjuIK1q_8ugA:10 a=BaG7jsApzVfQP5CKn1ndzA==:117 X-CMAE-OUT-Score: 0.00 Received: from localhost (smallrivers1.epfl.ch [128.179.67.51]) (Authenticated sender: pyritschard@smallrivers.com) by emta003.roc2.bluetie.com (Postfix) with ESMTP id 3F24F11D0178 for ; Wed, 21 Dec 2011 06:35:45 -0500 (EST) Date: Wed, 21 Dec 2011 12:34:48 +0100 From: pyr@smallrivers.com To: user@cassandra.apache.org Subject: Handling topology changes Message-ID: <20111221113448.GA26219@omega> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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