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 7FED09F3F for ; Wed, 15 Aug 2012 03:48:39 +0000 (UTC) Received: (qmail 94460 invoked by uid 500); 15 Aug 2012 03:48:37 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 93902 invoked by uid 500); 15 Aug 2012 03:48:32 -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 93875 invoked by uid 99); 15 Aug 2012 03:48:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2012 03:48:31 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a56.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2012 03:48:24 +0000 Received: from homiemail-a56.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a56.g.dreamhost.com (Postfix) with ESMTP id ADC82FE05B for ; Tue, 14 Aug 2012 20:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :content-type:message-id:mime-version:subject:date:references:to :in-reply-to; s=thelastpickle.com; bh=s1yyZzLWlRRqM+JuHG2fTpCCh1 8=; b=uhjImyosVLs1az1RBnY/fi53d0R6E8ANwtc0bLt50wYqa16beuSvz7DyBf NeHhac9qiylbQLELitK/jkV0pmuDSEkgVqZarP4XTlON9cm/vAyY0Pr4nW87p8SH vEGOOckH8eifqdJyc3fLQZUFgAjYbblYgPD3CBdg2ShWIrkh4= Received: from [192.168.2.77] (unknown [116.90.132.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a56.g.dreamhost.com (Postfix) with ESMTPSA id 351F6FE059 for ; Tue, 14 Aug 2012 20:48:02 -0700 (PDT) From: aaron morton Content-Type: multipart/alternative; boundary="Apple-Mail=_0E292A58-9C88-49DF-B6A8-CE945F9427AE" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Subject: Re: replace dead node? " token -1 " Date: Wed, 15 Aug 2012 15:48:00 +1200 References: To: user@cassandra.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1485) --Apple-Mail=_0E292A58-9C88-49DF-B6A8-CE945F9427AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > Using this method, when choosing the new , should we still use = the T-1 ? (AFAIK) No.=20 replace_token is used when you want to replace a node that is dead. In = this case the dead node will be identified by its token. > if so, would the duplicate token (same token but different ip) cause = problems? If the nodes are bootstrapping an error is raised.=20 Otherwise the token ownership is passed to the new node.=20 Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 15/08/2012, at 11:07 AM, Yang wrote: > previously when a node dies, I remember the documents describes that = it's better to assign T-1 to the new node, > where T was the token of the dead node. >=20 >=20 > the new doc for 1.x here >=20 > http://wiki.apache.org/cassandra/Operations#Replacing_a_Dead_Node >=20 >=20 > shows a new way to pass in cassandra.replace_token=3D =20 > for the new node. =20 > Using this method, when choosing the new , should we still use = the T-1 ? >=20 >=20 > Also in Priam code: > = https://github.com/Netflix/Priam/blob/master/priam/src/main/java/com/netfl= ix/priam/identity/InstanceIdentity.java >=20 > line 148, it does not seem that Priam does the "-1" thing, but assigns = the original token T to the new node. > if so, would the duplicate token (same token but different ip) cause = problems? >=20 >=20 > Thanks > Yang --Apple-Mail=_0E292A58-9C88-49DF-B6A8-CE945F9427AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Using this method, when choosing the new = <Token>, should we still use the T-1 ?
(AFAIK) = No. 
replace_token is used when you want to replace a = node that is dead. In this case the dead node will be identified by its = token.

if so, would = the duplicate token (same token but different ip) cause = problems?
If the nodes are bootstrapping an error = is raised. 
Otherwise the token ownership is passed to = the new = node. 

Cheers

http://www.thelastpickle.com

On 15/08/2012, at 11:07 AM, Yang <teddyyyy123@gmail.com> = wrote:

previously when a node dies, I remember the documents = describes that it's better to assign T-1 to the new = node,
where T was the token of the dead = node.


the new doc for 1.x = here

http://wiki.apache.org/cassandra/Operations#Replacing_a_Dead_Node

shows a new way to  pass = in cassandra.replace_token=3D<Token> =  
for the new node.  
Using this method, when choosing = the new <Token>, should we still use the T-1 = ?


Also in Priam = code:

line 148, it does not seem that Priam does the "-1" = thing, but assigns the original token T to the new node.
if = so, would the duplicate token (same token but different ip) cause = problems?


Thanks
Yang

= --Apple-Mail=_0E292A58-9C88-49DF-B6A8-CE945F9427AE--