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 8D8B5EEE8 for ; Thu, 21 Feb 2013 14:45:29 +0000 (UTC) Received: (qmail 43164 invoked by uid 500); 21 Feb 2013 14:45:26 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 42779 invoked by uid 500); 21 Feb 2013 14:45:23 -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 42749 invoked by uid 99); 21 Feb 2013 14:45:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Feb 2013 14:45:22 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jaluce06@gmail.com designates 209.85.212.43 as permitted sender) Received: from [209.85.212.43] (HELO mail-vb0-f43.google.com) (209.85.212.43) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Feb 2013 14:45:17 +0000 Received: by mail-vb0-f43.google.com with SMTP id fs19so5753232vbb.2 for ; Thu, 21 Feb 2013 06:44:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=+Ul1RNpy9U0pJ/+A5IFLBin5Axbz+l8Je0n1kBjdpH0=; b=jwS4ktZyd/TJ/bFnmel2oT3qPGwlOjrGjBMJAiyZm0hIAwnh6NNtpbpbzJ1Y0yukfX odFDXsdn3ZZoBdblLX0SdL6y249lra4fo3t2axe7ctlMdm42+DxXx9nod1S8Ey/yF4bN /+Gv52j0qlsMSLJcZnvxftUCtvqfiU3tglDa4feylrzddgVjd9VwrBofxRbgcFDrikJb 71PGKrj9puCDTUahbq+KnWDJBOPLzu9Ff+lCy1MFtUebetP1QdEt3INluL2kX2n+DBL/ RznSxCOmAtRv1kjUb3NNpZdecpU2DLsIWsUvREWSnXGZZLWuPWxUfZx7UEVnkKvcKb0a RFfw== MIME-Version: 1.0 X-Received: by 10.220.208.137 with SMTP id gc9mr26374894vcb.51.1361457895995; Thu, 21 Feb 2013 06:44:55 -0800 (PST) Received: by 10.58.237.195 with HTTP; Thu, 21 Feb 2013 06:44:55 -0800 (PST) Date: Thu, 21 Feb 2013 15:44:55 +0100 Message-ID: Subject: Adding new nodes in a cluster with virtual nodes From: Jean-Armel Luce To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=bcaec54fb0fc44795904d63d1e4e X-Virus-Checked: Checked by ClamAV on apache.org --bcaec54fb0fc44795904d63d1e4e Content-Type: text/plain; charset=ISO-8859-1 Hello, We are using Cassandra 1.2.0. We have a cluster of 16 physical nodes, each node has 256 virtual nodes. We want to add 2 new nodes in our cluster : we follow the procedure as explained here : http://www.datastax.com/docs/1.2/operations/add_replace_nodes. After starting 1 of the new node, we can see that this new node has 256 tokens ==>looks good We can see that this node is in the ring (using nodetool status) ==> looks good After the bootstrap is finished in the new node, no data has been moved automatically from the old nodes to this new node. However, when we send insert queries in our cluster, the new node accepts to insert the new rows. Please, could you tell me if we need to perform a nodetool repair after the bootstrap of the new node ? What happens if we perform a nodetool cleanup in the old nodes before doing the nodetool repair ? (Is there a risk of loosing some data ?) Regards. Jean Armel --bcaec54fb0fc44795904d63d1e4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

We are using Cassandra 1.2.0.
We have a cluster of 16 phys= ical nodes, each node has 256 virtual nodes.
We want to add 2 new nodes = in our cluster : we follow the procedure as explained here : http://www.data= stax.com/docs/1.2/operations/add_replace_nodes.

After starting 1 of the new node, we can see that this new node has 256= tokens =3D=3D>looks good
We can see that this node is in the ring (u= sing nodetool status) =3D=3D> looks good
After the bootstrap is finis= hed in the new node, no data has been moved automatically from the old node= s to this new node.


However, when we send insert queries in our cluster, the new node a= ccepts to insert the new rows.

Please, could you tell me if we need = to perform a nodetool repair after the bootstrap of the new node ?
What happens if we perform a nodetool cleanup in the old nodes before doing= the nodetool repair ? (Is there a risk of loosing some data ?)

Rega= rds.

Jean Armel
--bcaec54fb0fc44795904d63d1e4e--