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 378BA10AEA for ; Fri, 21 Jun 2013 12:26:50 +0000 (UTC) Received: (qmail 67314 invoked by uid 500); 21 Jun 2013 12:26:44 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 67021 invoked by uid 500); 21 Jun 2013 12:26:43 -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 66530 invoked by uid 99); 21 Jun 2013 12:26:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Jun 2013 12:26:42 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mightye@gmail.com designates 209.85.215.48 as permitted sender) Received: from [209.85.215.48] (HELO mail-la0-f48.google.com) (209.85.215.48) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Jun 2013 12:26:36 +0000 Received: by mail-la0-f48.google.com with SMTP id lx15so7154650lab.35 for ; Fri, 21 Jun 2013 05:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=67yXYMFmOHmTeLD9AL2nxQOKZEJVK0YjwJEJSgONQfA=; b=CQpUp75dn0aatRWbLPknhck/clAzFbTwZunuCQ5WUUAFmUw+kL7KW84Ut2ZHLEntIM ln5agF0g7ynIUrQEDdVeVOreqq8Z11sx2Cy8IIQJgVbRaLjhBCg8NVoQocOtXs5ORxEM 3yLOHfk2yaW2b5tjHvKCxm1SE17RlDTjm64f+CHpWlkNobARNVszaG7+cX4omFjZGUkB 1wT2Bz32cLORwZkYyEYRTfZspJuyEVXlE10g6DBWqNu4V+4Sxo1bNNlWP+H2B1bzwkr2 W8/xCN0HNIKaqm5Wscv3nxtGEQiAcCP977MasT1jgwdOZpZmz6OESKXQd7LQXh4xjKVw 1Mhw== X-Received: by 10.152.88.42 with SMTP id bd10mr5795270lab.32.1371817575735; Fri, 21 Jun 2013 05:26:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.128.194 with HTTP; Fri, 21 Jun 2013 05:25:54 -0700 (PDT) In-Reply-To: References: <1371750027.91197.YahooMailNeo@web162006.mail.bf1.yahoo.com> From: Eric Stevens Date: Fri, 21 Jun 2013 08:25:54 -0400 Message-ID: Subject: Re: [Cassandra] Replacing a cassandra node To: user@cassandra.apache.org Cc: Emalayan Vairavanathan Content-Type: multipart/alternative; boundary=001a11c350984c686c04dfa92b01 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c350984c686c04dfa92b01 Content-Type: text/plain; charset=UTF-8 Is there a way to replace a failed server using vnodes? I only had occasion to do this once, on a relatively small cluster. At the time I just needed to get the new server online and wasn't concerned about the performance implications, so I just removed the failed server from the cluster and bootstrapped a new one. Of course that caused a bunch of key reassignments, so I'm sure it would be less work for the cluster if I could bring a new server online with the same vnodes as the failed server. On Thu, Jun 20, 2013 at 2:40 PM, Robert Coli wrote: > On Thu, Jun 20, 2013 at 10:40 AM, Emalayan Vairavanathan > wrote: > > In the case where replace a cassandra node (call it node A) with another > one > > that has the exact same IP (ie. during a node failure), what exactly > should > > we do? Currently I understand that we should at least run "nodetool > > repair". > > If you lost the data from the node, then what you want is "replace_token." > > If you didn't lose the data from the node (and can tolerate stale > reads until the repair completes) you want to start the node with > auto_bootstrap set to false and then repair. > > =Rob > --001a11c350984c686c04dfa92b01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there a way to replace a failed server using vnodes? = =C2=A0I only had occasion to do this once, on a relatively small cluster. = =C2=A0At the time I just needed to get the new server online and wasn't= concerned about the performance implications, so I just removed the failed= server from the cluster and bootstrapped a new one. =C2=A0Of course that c= aused a bunch of key reassignments, so I'm sure it would be less work f= or the cluster if I could bring a new server online with the same vnodes as= the failed server.


On Thu, Jun 2= 0, 2013 at 2:40 PM, Robert Coli <rcoli@eventbrite.com> wr= ote:
On Thu, Jun 20, 2013 at 10= :40 AM, Emalayan Vairavanathan
<svemalayan@yahoo.com> wr= ote:
> In the case where replace a cassandra node (call it node A) with anoth= er one
> that has the exact same IP (ie. during a node failure), what exactly s= hould
> we do? =C2=A0Currently I understand that we should at least run "= nodetool
> repair".

If you lost the data from the node, then what you want is "repla= ce_token."

If you didn't lose the data from the node (and can tolerate stale
reads until the repair completes) you want to start the node with
auto_bootstrap set to false and then repair.

=3DRob

--001a11c350984c686c04dfa92b01--