Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of mdennis@riptano.com designates
 74.125.83.47 as permitted sender)
MIME-Version: 1.0
Sender: mdennis@riptano.com
In-Reply-To: <1297811129888-6029708.post@n2.nabble.com>
References: <1297730719060-6025869.post@n2.nabble.com>
	<4d59cfab.d44de50a.486b.ffffb1f1@mx.google.com>
	<1297734749897-6025972.post@n2.nabble.com>
	<AANLkTikh22XCu1wKkPJW260K8gE0YPTma__rST67ZBBf@mail.gmail.com>
	<1297811129888-6029708.post@n2.nabble.com>
Date: Tue, 15 Feb 2011 17:09:42 -0600
Message-ID: <AANLkTinvyNLtMzhg7pHf67GEf1in4EjZL4td6VGxJk6D@mail.gmail.com>
Subject: Re: Data distribution
From: Matthew Dennis <mdennis@datastax.com>
To: user@cassandra.apache.org
Cc: cassandra-user@incubator.apache.org
Content-Type: multipart/alternative; boundary=90e6ba211d7d6d31c6049c5a4281

--90e6ba211d7d6d31c6049c5a4281
Content-Type: text/plain; charset=ISO-8859-1

Assuming you aren't changing the RC, the normal bootstrap process takes care
of all the problems like that, making sure things work correctly.

Most importantly, if something fails (either the new node or any of the
existing nodes) you can recover from it.

Just don't connect clients directly to that new node until it's fully in the
ring.

On Tue, Feb 15, 2011 at 5:05 PM, mcasandra <mohitanchlia@gmail.com> wrote:

>
> Is there a way to let the new node join cluster in the background and make
> it
> live to clients only after it has finished with node repair, syncing data
> etc. and in the end sync keys or trees that's needed before it's come to
> life. I know it can be tricky since it needs to be live as soon as it
> steals
> the keys.
>
> This ways we know we are adding nodes only when we think it's all ready.
> --
> View this message in context:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Data-distribution-tp6025869p6029708.html
> Sent from the cassandra-user@incubator.apache.org mailing list archive at
> Nabble.com.
>

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

Assuming you aren&#39;t changing the RC, the normal bootstrap process takes=
 care of all the problems like that, making sure things work correctly.<br>=
<br>Most importantly, if something fails (either the new node or any of the=
 existing nodes) you can recover from it.<br>
<br>Just don&#39;t connect clients directly to that new node until it&#39;s=
 fully in the ring.<br><br><div class=3D"gmail_quote">On Tue, Feb 15, 2011 =
at 5:05 PM, mcasandra <span dir=3D"ltr">&lt;<a href=3D"mailto:mohitanchlia@=
gmail.com">mohitanchlia@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Is there a way to let the new node join cluster in the background and make =
it<br>
live to clients only after it has finished with node repair, syncing data<b=
r>
etc. and in the end sync keys or trees that&#39;s needed before it&#39;s co=
me to<br>
life. I know it can be tricky since it needs to be live as soon as it steal=
s<br>
the keys.<br>
<br>
This ways we know we are adding nodes only when we think it&#39;s all ready=
.<br>
<font color=3D"#888888">--<br>
View this message in context: <a href=3D"http://cassandra-user-incubator-ap=
ache-org.3065146.n2.nabble.com/Data-distribution-tp6025869p6029708.html" ta=
rget=3D"_blank">http://cassandra-user-incubator-apache-org.3065146.n2.nabbl=
e.com/Data-distribution-tp6025869p6029708.html</a><br>

</font><div><div></div><div class=3D"h5">Sent from the <a href=3D"mailto:ca=
ssandra-user@incubator.apache.org">cassandra-user@incubator.apache.org</a> =
mailing list archive at Nabble.com.<br>
</div></div></blockquote></div><br>

--90e6ba211d7d6d31c6049c5a4281--