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 casey@deccio.net designates
 209.85.212.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACHzRHYkFe9MRq0N7-P0-+sr2Smik4ZV3zahPDUWZQeZUbgFiw@mail.gmail.com>
References: 
 <CAEKtLiR4xdYSCUBKH+TuW68Vxamto-8VbzqxK3zGhv3g3i=aWw@mail.gmail.com>
	<CACHzRHYkFe9MRq0N7-P0-+sr2Smik4ZV3zahPDUWZQeZUbgFiw@mail.gmail.com>
Date: Thu, 30 Aug 2012 22:39:08 -0700
Message-ID: 
 <CAEKtLiT8nq=pYxQj3GB2JsLJoeBEHKC2VyzrbRq7SjkvMqsguA@mail.gmail.com>
Subject: Re: adding node to cluster
From: Casey Deccio <casey@deccio.net>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=f46d042fdb3ef96a2204c889353e

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

On Thu, Aug 30, 2012 at 11:21 AM, Rob Coli <rcoli@palominodb.com> wrote:

> On Thu, Aug 30, 2012 at 10:18 AM, Casey Deccio <casey@deccio.net> wrote:
> > I'm adding a new node to an existing cluster that uses
> > ByteOrderedPartitioner.  The documentation says that if I don't
> configure a
> > token, then one will be automatically generated to take load from an
> > existing node.
> > What I'm finding is that when I add a new node, (super)
> > column lookups begin failing (not sure if it was the row lookup failing
> or
> > the supercolumn lookup failing), and I'm not sure why.
>
> 1) You almost never actually want BOP.
> 2) You never want Cassandra to pick a token for you. IMO and the
> opinion of many others, the fact that it does this is a bug. Specify a
> token with initial_token.
> 3) You never want to use Supercolumns. The project does not support
> them but currently has no plan to deprecate them. Use composite row
> keys.
> 4) Unless your existing cluster consists of one node, you almost never
> want to add only a single new node to a cluster. In general you want
> to double it.
>
> In summary, you are Doing It just about as Wrong as possible... but on
> to your actual question ... ! :)
>
>
Well, at least I'm consistent :)  Thanks for the hints.  Unfortunately,
when I first brought up my system--with the goal of getting it up
quickly--I thought BOP and Supercolumns were the way to go.  Plus, the
small "cluster" of nodes I was using was on a hodgepodge of hardware.  I've
since had a chance to think somewhat about redesigning and rearchitecting,
but it seems like there's no "easy" way to convert it properly.  Step one
was to migrate everything over to a single dedicated node on reasonable
hardware, so I could begin the process, which brought me to the issue I
initially posted about.  But the problem is that this is a live system, so
data loss is an issue I'd like to avoid.


> In what way are the lookups "failing"? Is there an exception?
>
>
No exception--just failing in that the data should be there, but isn't.

Casey

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

On Thu, Aug 30, 2012 at 11:21 AM, Rob Coli <span dir=3D"ltr">&lt;<a href=3D=
"mailto:rcoli@palominodb.com" target=3D"_blank">rcoli@palominodb.com</a>&gt=
;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div class=3D"im">On Thu, Aug 30, 2012 at 10:18 AM, Casey Deccio &lt;<a hre=
f=3D"mailto:casey@deccio.net">casey@deccio.net</a>&gt; wrote:<br>
&gt; I&#39;m adding a new node to an existing cluster that uses<br>
&gt; ByteOrderedPartitioner. =A0The documentation says that if I don&#39;t =
configure a<br>
&gt; token, then one will be automatically generated to take load from an<b=
r>
&gt; existing node.<br>
&gt; What I&#39;m finding is that when I add a new node, (super)<br>
&gt; column lookups begin failing (not sure if it was the row lookup failin=
g or<br>
&gt; the supercolumn lookup failing), and I&#39;m not sure why.<br>
<br>
</div>1) You almost never actually want BOP.<br>
2) You never want Cassandra to pick a token for you. IMO and the<br>
opinion of many others, the fact that it does this is a bug. Specify a<br>
token with initial_token.<br>
3) You never want to use Supercolumns. The project does not support<br>
them but currently has no plan to deprecate them. Use composite row<br>
keys.<br>
4) Unless your existing cluster consists of one node, you almost never<br>
want to add only a single new node to a cluster. In general you want<br>
to double it.<br>
<br>
In summary, you are Doing It just about as Wrong as possible... but on<br>
to your actual question ... ! :)<br>
<br></blockquote><div><br>Well, at least I&#39;m consistent :)=A0 Thanks fo=
r the hints.=A0 Unfortunately, when I first brought up my system--with the =
goal of getting it up quickly--I thought BOP and Supercolumns were the way =
to go.=A0 Plus, the small &quot;cluster&quot; of nodes I was using was on a=
 hodgepodge of hardware.=A0 I&#39;ve since had a chance to think somewhat a=
bout redesigning and rearchitecting, but it seems like there&#39;s no &quot=
;easy&quot; way to convert it properly.=A0 Step one was to migrate everythi=
ng over to a single dedicated node on reasonable hardware, so I could begin=
 the process, which brought me to the issue I initially posted about.=A0 Bu=
t the problem is that this is a live system, so data loss is an issue I&#39=
;d like to avoid.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In what way are the lookups &quot;failing&quot;? Is there an exception?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br>No exception--just failing in that the data should be there, bu=
t isn&#39;t.<br><br>Casey<br></div></div>

--f46d042fdb3ef96a2204c889353e--