Return-Path: 
 <user-return-9796-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org>
Delivered-To: apmail-cassandra-user-archive@www.apache.org
Received: (qmail 4652 invoked from network); 11 Oct 2010 08:42:31 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 11 Oct 2010 08:42:31 -0000
Received: (qmail 55889 invoked by uid 500); 11 Oct 2010 08:42:29 -0000
Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org
Received: (qmail 55777 invoked by uid 500); 11 Oct 2010 08:42:25 -0000
Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@cassandra.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@cassandra.apache.org>
List-Post: <mailto:user@cassandra.apache.org>
List-Id: <user.cassandra.apache.org>
Reply-To: user@cassandra.apache.org
Delivered-To: mailing list user@cassandra.apache.org
Received: (qmail 55767 invoked by uid 99); 11 Oct 2010 08:42:24 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 08:42:24 +0000
X-ASF-Spam-Status: No, hits=2.2 required=10.0
	tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of chen.daqi@gmail.com designates
 74.125.82.172 as permitted sender)
Received: from [74.125.82.172] (HELO mail-wy0-f172.google.com) (74.125.82.172)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 08:42:17 +0000
Received: by wyb29 with SMTP id 29so459999wyb.31
        for <user@cassandra.apache.org>; Mon, 11 Oct 2010 01:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:date:message-id
         :subject:from:to:content-type;
        bh=HlRR270QUtffHkGtpzwpPdMX9WhoZO0HIO9FSbsg+Dg=;
        b=ipiLnFeFiwmTB7+xYmuokDXhVZL0QndfImnEJUg1M48DPo7Cs6gWrGXJZUgETq2RcH
         vq8JdHRjmNDxAIXudfRV5XT8PMfmzJ+PAAdzQKWDuCiOU8uJHlvqijCYE5mcIqr+cBdY
         e0GHfTV7+HfbRM7ISP0pRcCei3Yv+SdnKSAbg=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=wV+oDsLffVUe/QP7CzPElBoctSDJzr2vN0UJWY6y2A407Js43XNN95NijmGitAJPWD
         WEM2qNfC6+VJdrGKussq/kImQttw3C+7MVGQqpY8dPtOZF2ifpQHobLbPurEDF3gGV/t
         z9445gtyPlbtBu0TWa186C7X7TtZuVx/xHaoM=
MIME-Version: 1.0
Received: by 10.227.153.15 with SMTP id i15mr5082797wbw.211.1286786517167;
 Mon, 11 Oct 2010 01:41:57 -0700 (PDT)
Received: by 10.227.130.205 with HTTP; Mon, 11 Oct 2010 01:41:57 -0700 (PDT)
Date: Mon, 11 Oct 2010 16:41:57 +0800
Message-ID: <AANLkTi=GB+N3URpz6xHuY6+g+ohmuBLFv0tjn4CUjd_a@mail.gmail.com>
Subject: replacing a dead node
From: Chen Xinli <chen.daqi@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=001485f94bb241eeeb0492535599
X-Virus-Checked: Checked by ClamAV on apache.org

--001485f94bb241eeeb0492535599
Content-Type: text/plain; charset=ISO-8859-1

Hi,

We have a cassandra cluster of 6 nodes with RF=3, read-repair enabled,
hinted handoff disabled, WRITE with QUORUM, READ with ONE.
we want to rely on read-repair totally for node failure, as returning
inconsistent result temporarily is ok for us.

If a node is temporarily dead and returneded to the cluster later,
everything seems fine.
If a node is damaged and a new node with different IP is added, can I just
assign dead node's initialToken to him and have read-repair handle
everything?

I have read the wiki:
http://www.riptano.com/docs/0.6.5/operations/clustering .
But in order to keep it simple, I don't want to use autobootstrap,
noderepair, removetoken, etc

-- 
Best Regards,
Chen Xinli

--001485f94bb241eeeb0492535599
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, <br><br>We have a cassandra cluster of 6 nodes with RF=3D3, read-repair=
 enabled, hinted handoff disabled, WRITE with QUORUM, READ with ONE.<br>we =
want to rely on read-repair totally for node failure, as returning inconsis=
tent result temporarily is ok for us.<br>
<br>If a node is temporarily dead and returneded to the cluster later, ever=
ything seems fine.<br>If a node is damaged and a new node with different IP=
 is added, can I just assign dead node&#39;s initialToken to him and have r=
ead-repair handle everything?<br>
<br>I have read the wiki: <a href=3D"http://www.riptano.com/docs/0.6.5/oper=
ations/clustering">http://www.riptano.com/docs/0.6.5/operations/clustering<=
/a> . <br>But in order to keep it simple, I don&#39;t want to use autoboots=
trap, noderepair, removetoken, etc<br clear=3D"all">
<br>-- <br>Best Regards,<br>Chen Xinli<br>

--001485f94bb241eeeb0492535599--