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 A8B3E185CB for ; Fri, 27 Nov 2015 00:50:53 +0000 (UTC) Received: (qmail 50038 invoked by uid 500); 27 Nov 2015 00:50:50 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 49992 invoked by uid 500); 27 Nov 2015 00:50:50 -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 49981 invoked by uid 99); 27 Nov 2015 00:50:50 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Nov 2015 00:50:50 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id CAE6E180ACC for ; Fri, 27 Nov 2015 00:50:49 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.901 X-Spam-Level: ** X-Spam-Status: No, score=2.901 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 4LMRpCRNYLWp for ; Fri, 27 Nov 2015 00:50:36 +0000 (UTC) Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id B991A2050F for ; Fri, 27 Nov 2015 00:50:35 +0000 (UTC) Received: by vkha189 with SMTP id a189so60718759vkh.2 for ; Thu, 26 Nov 2015 16:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cKE8KwiD4v6WAtJ+o0YWguLvbCFSML4B5QKszkGBS60=; b=j4Svw7wZa+t0s3d6nqJunboZ+t8AxDQ8+0K+H6cPnBUmmB40tdIoNDdmd/u9vutPF4 kQaNDn7Tx3gad0MsSWaPwCw2mogIkQy5jS3mjSAORhGHeD0kJwiffKQaC3As4N4RyvIk XnaOkHfkH6L92Wg3AUk1KWI2rhbH5vdw9rbBoXTc3/Y+kIgFNzhJOf3+Vz3EmQAyLF96 nal7jC7Awox/NNjEWH6tKmFCKf+0jcxvoCgaGFhYpUqlzev7o3KEzITJn60df5WlQV11 TyUPvtKdBuAWmMX1GHgq4zX2ANy76Phv8eqMsdmi8CSCfCvMJym+Pjc7ZHPlllqe19YO SJfw== MIME-Version: 1.0 X-Received: by 10.31.167.20 with SMTP id q20mr40334363vke.79.1448585429029; Thu, 26 Nov 2015 16:50:29 -0800 (PST) Received: by 10.31.47.137 with HTTP; Thu, 26 Nov 2015 16:50:28 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Nov 2015 19:50:28 -0500 Message-ID: Subject: Re: Change the rack of a server From: Jack Krupansky To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11415c7aec96dc05257b132d --001a11415c7aec96dc05257b132d Content-Type: text/plain; charset=UTF-8 Right, and I also meant to refer to the anti-pattern doc related to racks: http://docs.datastax.com/en/cassandra/2.0/cassandra/architecture/architecturePlanningAntiPatterns_c.html Although that doc seems to discourage rack selection entirely when in fact people should try to have replicas placed in separate racks since a lot of failures tend to be due to power, cooling, and network switching at the rack level (or so I have heard but have no personal experience.) -- Jack Krupansky On Thu, Nov 26, 2015 at 7:41 PM, Paulo Motta wrote: > Changing the rack of a live node is discouraged, since the ring ranges the > node is responsible for will change, meaning the node will not own part of > the data for its new ranges and other nodes may not have some of its > current data. > > It will be a forbidden operation in the upcoming versions of Cassandra, > since it has caused trouble before, see > https://issues.apache.org/jira/browse/CASSANDRA-10242 for more > background. The safest thing is to decommission the node and bootstrap the > node again in a new rack, as Jack suggested. > > 2015-11-26 14:40 GMT-08:00 Jack Krupansky : > >> What RF are you using? How many data centers? What rack configuration are >> you currently using/ Are you in fact using a rack-aware network topology >> partitioner? >> >> Specifically, what are you attempting to accomplish - why change the rack >> at all? Not that changing the rack is necessarily bad, just to clarify your >> objective. >> >> See: >> >> http://docs.datastax.com/en/cassandra/2.0/cassandra/architecture/architectureDataDistributeReplication_c.html >> >> You may just have to bootstrap the new node with the proper rack and then >> run repair on the nodes which formerly held replicas of the old node. >> >> Or, you may have to run a full repair for all nodes of the cluster: >> >> http://docs.datastax.com/en/cassandra/2.0/cassandra/operations/opsMoveNodeRack.html >> >> >> -- Jack Krupansky >> >> On Thu, Nov 26, 2015 at 4:02 AM, Badrjan wrote: >> >>> So I have a 8 node cluster and I would like to change the rack of one >>> node. How should I do that? >>> >>> B. >>> >> >> > --001a11415c7aec96dc05257b132d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, and I also meant to refer to the anti-pattern doc r= elated to racks:

Although that doc seems = to discourage rack selection entirely when in fact people should try to hav= e replicas placed in separate racks since a lot of failures tend to be due = to power, cooling, and network switching at the rack level (or so I have he= ard but have no personal experience.)

-- = Jack Krupansky

On Thu, Nov 26, 2015 at 7:41 PM, Paulo Motta= <pauloricardomg@gmail.com> wrote:
Changing the rack of a live node is= discouraged, since the ring ranges the node is responsible for will change= , meaning the node=C2=A0 will not own part of the data for its new ranges a= nd other nodes may not have some of its current data.

It will = be a forbidden operation in the upcoming versions of Cassandra, since it ha= s caused trouble before, see https://issues.apache.org/jira/browse= /CASSANDRA-10242 for more background. The safest thing is to decommissi= on the node and bootstrap the node again in a new rack, as Jack suggested.<= br>

2015-11-26 14:40 GMT-08:00 Jack Krupansky <= span dir=3D"ltr"><jack.krupansky@gmail.com>:
What RF are you using? How many data centers? What= rack configuration are you currently using/ Are you in fact using a rack-a= ware network topology partitioner?

Specifically, what ar= e you attempting to accomplish - why change the rack at all? Not that chang= ing the rack is necessarily bad, just to clarify your objective.
=
See:
You may just have to bootstrap the new node with the proper ra= ck and then run repair on the nodes which formerly held replicas of the old= node.

Or, you may have to run a full repair for a= ll nodes of the cluster:


-- Jack Krupansky
On Thu, Nov 26, 2015 at 4:02 AM, Badrjan <bad= rjan@tuta.io> wrote:
=20 =20 =20
So I have a 8 node cluster and I would like to change the rack of one node.= How should I do that?=C2=A0

B.
=



--001a11415c7aec96dc05257b132d--