Return-Path: Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org Received: (qmail 69518 invoked from network); 1 Oct 2009 17:15:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Oct 2009 17:15:53 -0000 Received: (qmail 46235 invoked by uid 500); 1 Oct 2009 17:15:53 -0000 Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org Received: (qmail 46213 invoked by uid 500); 1 Oct 2009 17:15:53 -0000 Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-user@incubator.apache.org Delivered-To: mailing list cassandra-user@incubator.apache.org Received: (qmail 46204 invoked by uid 99); 1 Oct 2009 17:15:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 17:15:53 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ikatkov@gmail.com designates 209.85.220.209 as permitted sender) Received: from [209.85.220.209] (HELO mail-fx0-f209.google.com) (209.85.220.209) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 17:15:43 +0000 Received: by fxm5 with SMTP id 5so341368fxm.27 for ; Thu, 01 Oct 2009 10:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=fOJv0bKDdGsMjMnXEPK9CFioB4L+v3iZrSV2iKYMSOA=; b=QOhx10clT45D4MdS969RVEdUC81OzsP5l+vTwagBCf+TV8C/YREOT9PVyTG2eVw/4Q rX/+A8IoQczmcK4hY2ih2x2gMyWVBYksoVrM2GPF0hP4MzqmwwJRVbWG9pznxxUrmjO/ TYWhMb0eOAhI/T4TF9jElgvUOswZWpdTRd9A8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=dLbs6nQv389eA8OkGEJckqaiHdK0yHRKfRwztgYs70IcrloaCFg4jcT9n4SYlzq0as +sehxjbyRvcloe3D5EjEvlC5IILiF+nlL1P8StjEqx/u9dyoZuQFWlz0XjQUu/Wak4jB 62fR0yrVbzr55DqPNPhhTi4igApV7s9wODyoE= MIME-Version: 1.0 Received: by 10.223.16.216 with SMTP id p24mr451274faa.35.1254417263094; Thu, 01 Oct 2009 10:14:23 -0700 (PDT) In-Reply-To: References: <23b1e84e0910010926w65e08b7dke62d6c615e441645@mail.gmail.com> From: Igor Katkov Date: Thu, 1 Oct 2009 13:14:03 -0400 Message-ID: <23b1e84e0910011014s3cad1889na7b6b3d37485789f@mail.gmail.com> Subject: Re: distributing tokens equally along the key distribution space To: cassandra-user@incubator.apache.org Content-Type: multipart/alternative; boundary=00151747965a5dec9f0474e2c701 X-Virus-Checked: Checked by ClamAV on apache.org --00151747965a5dec9f0474e2c701 Content-Type: text/plain; charset=ISO-8859-1 What is the correct procedure for data re-partitioning? Suppose I have 3 nodes - "A", "B", "C" tokens on the ring: A: 0 B: 2.8356863910078205288614550619314e+37 C: 5.6713727820156410577229101238628e+37 Then I add node "D", token: 1.4178431955039102644307275309655e+37 (B/2) Start node "D" with -b Wait Run nodeprobe -host hostB ... cleanup on live "B" Wait Done Now data is not evenly balanced because tokens are not evenly spaced. I see that there is tokenupdater (org.apache.cassandra.tools.TokenUpdater) What happens with keys and data if I run it on "A", "B", "C" and "D" with new, better spaced tokens? Should I? is there a better procedure? On Thu, Oct 1, 2009 at 12:48 PM, Jonathan Ellis wrote: > On Thu, Oct 1, 2009 at 11:26 AM, Igor Katkov wrote: > > Hi, > > > > Question#1: > > How to manually select tokens to force equal spacing of tokens around the > > hash space? > > (Answered by Jun.) > > > Question#2: > > Let's assume that #1 was resolved somehow and key distribution is more or > > less even. > > A new node "C" joins the cluster. It's token falls somewhere between two > > other tokens on the ring (from nodes "A" and "B" clockwise-ordered). From > > now on "C" is responsible for a portion of data that used to exclusively > > belong to "B". > > a. Cassandra v.0.4 will not automatically transfer this data to "C" will > it? > > It will, if you start C with the -b ("bootstrap") flag. > > > b. Do all reads to these keys fail? > > No. > > > c. What happens with the data reference by these keys on "B"? It will > never > > be accessed there, therefor it becomes garbage. Since there are to GC > will > > it stick forever? > > nodeprobe cleanup after the bootstrap completes will instruct B to > throw out data that has been copied to C. > > > d. What happens to replicas of these keys? > > These are also handled by -b. > > -Jonathan > --00151747965a5dec9f0474e2c701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What is the correct procedure for data re-partitioning?
Suppose I have 3= nodes - "A", "B", "C"
tokens on the ring= :
A: 0
B: 2.8356863910078205288614550619314e+37
C: 5.6713727820156= 410577229101238628e+37

Then I add node "D", token: 1.4178431955039102644307275309655= e+37 (B/2)
Start node "D" with -b
Wait
Run nodeprobe -ho= st hostB ... cleanup on live "B"
Wait
Done

Now data = is not evenly balanced because tokens are not evenly spaced. I see that the= re is tokenupdater (org.apache.cassandra.tools.TokenUpdater)
What happens with keys and data if I run it on "A", "B"= , "C" and "D" with new, better spaced tokens? Should I?= is there a better procedure?




On Thu, Oct 1, 2009 at 12:48 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
=
On Thu, Oct 1, 2009 at 11:26 AM, Igor Katkov <ikatkov@gmail.com> wrote:
> Hi,
>
> Question#1:
> How to manually select tokens to force equal spacing of tokens around = the
> hash space?

(Answered by Jun.)

> Question#2:
> Let's assume that #1 was resolved somehow and key distribution is = more or
> less even.
> A new node "C" joins the cluster. It's token falls somew= here between two
> other tokens on the ring (from nodes "A" and "B" c= lockwise-ordered). From
> now on "C" is responsible for a portion of data that used to= exclusively
> belong to "B".
> a. Cassandra v.0.4 will not automatically transfer this data to "= C" will it?

It will, if you start C with the -b ("bootstrap") flag.

> b. Do all reads to these keys fail?

No.

> c. What happens with the data reference by these keys on "B"= ? It will never
> be accessed there, therefor it becomes garbage. Since there are to GC = will
> it stick forever?

nodeprobe cleanup after the bootstrap completes will instruct B to throw out data that has been copied to C.

> d. What happens to replicas of these keys?

These are also handled by -b.

-Jonathan

--00151747965a5dec9f0474e2c701--