Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of watanabe.maki@gmail.com
 designates 209.85.214.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=gvZjwys9YLvQV2Fa9eNjPPNpAp7eh/sJiSazQUfDq3TiPv1iroQBIDn0SYXLJYc57V
         XKoPmTeYgscOfOpw72H01ZPyY0jkxhTljVUB2Kkm89Wb6cx9GvQRaKeU3R94baVrXhKS
         nPAva3cbFw3gQVLXZl4EBFKyXveEuZhPA802M=
MIME-Version: 1.0
In-Reply-To: <AFE70D36-95C7-4A34-8469-5F3781ABC76E@sgizmo.com>
References: <2F578912-1E00-4541-BA95-01815151888D@sgizmo.com>
	<BANLkTimg3Dxr+NPo_puo2_Ptnz5sZTgc1Q@mail.gmail.com>
	<AFE70D36-95C7-4A34-8469-5F3781ABC76E@sgizmo.com>
Date: Sat, 14 May 2011 07:24:45 -0700
Message-ID: <BANLkTi=RYieVGvRAiMCwdg5AhjbJsghc4A@mail.gmail.com>
Subject: Re: Inconsistent data issues when running nodetool move.
From: Maki Watanabe <watanabe.maki@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If you do CL=3DONE write + CL=3DALL read, then it seems OK...
You should better to stay in this thread until some of experts would
answer your question.

2011/5/14 Ryan Hadley <ryan@sgizmo.com>:
> Thanks Maki,
>
> That makes sense with my symptoms... =A0I was doing a CL=3DONE for write =
and a CL=3DALL for read, expecting that to be sufficient.
>
> I will try both set to ALL and see if I get better consistency.
>
> -Ryan
>
> On May 14, 2011, at 4:41 AM, Maki Watanabe wrote:
>
>> It depends on what you really use which CL for your operations.
>> Your RF is 2, so if you read/write with CL=3DALL, your r/w will be
>> always consistent. If your read is CL=3DONE, you have chance to read old
>> data anytime, decommission is not matter. CL=3DQUORUM on RF=3D2 is
>> semantically identical with CL=3DALL.
>>
>> maki
>>
>> 2011/5/13 Ryan Hadley <ryan@sgizmo.com>:
>>> Hi,
>>>
>>> I'm running Cassandra (0.7.4) on a 4 node ring. =A0It was a 3 node ring=
, but we ended up expanding it to 4... So then I followed the many suggesti=
ons to rebalance the ring. =A0I found a script that suggested I use:
>>>
>>> # ~/nodes_calc.py
>>> How many nodes are in your cluster? 4
>>> node 0: 0
>>> node 1: 42535295865117307932921825928971026432
>>> node 2: 85070591730234615865843651857942052864
>>> node 3: 127605887595351923798765477786913079296
>>>
>>> So I started to migrate each node to those tokens.
>>>
>>> I have my replication factor set to 2, so I guess I was expecting to be=
 able to continue to use this ring without issues. =A0But it seems that the=
 node still accepts writes while it's decommissioning? =A0I say this becaus=
e if I interrupt the decommission by stopping Cassandra and starting it aga=
in, it appears to run through several commit logs. =A0And as soon as it's t=
hrough with those commit logs, I no longer get consistency issues.
>>>
>>> The issue I'm seeing is that writes to this ring will succeed, but it's=
 possible for a subsequent read to return an older object. =A0For several m=
inutes even.
>>>
>>> I'm not sure if I did something wrong... learning as I go here and this=
 list archive has been very useful. =A0But, is there anyway I can rebalance=
 the node and get better consistency?
>>>
>>> Thanks,
>>> Ryan
>
>


--=20
w3m