The consistency ALL was only for my testing so there could be a logical
explanation to this. We use LOCAL_QUORUM in prod.
Original message
From: Jack Krupansky
Date: 3/23/2016 4:56 PM (GMT-08:00)
To: user@cassandra.apache.org
Subject: Re: Rack aware question.
CL=ALL also
t; otherwise, it is done before returning the data.”
>>
>>
>>
>> I set consistency to ALL, and now I can get data all the time.
>>
>>
>>
>> *From:* Anubhav Kale [mailto:anubhav.k...@microsoft.com]
>> *Sent:* Wednesday, March 23, 2016 4:14 PM
&g
”
>
>
>
> I set consistency to ALL, and now I can get data all the time.
>
>
>
> *From:* Anubhav Kale [mailto:anubhav.k...@microsoft.com]
> *Sent:* Wednesday, March 23, 2016 4:14 PM
>
> *To:* user@cassandra.apache.org
> *Subject:* RE: Rack aware question.
&g
consistency to ALL, and now I can get data all the time.
From: Anubhav Kale [mailto:anubhav.k...@microsoft.com]
Sent: Wednesday, March 23, 2016 4:14 PM
To: user@cassandra.apache.org
Subject: RE: Rack aware question.
Thanks, Read repair is what I thought must be causing this, so I experimented
some
should
document it better ?
Thanks !
From: Paulo Motta [mailto:pauloricard...@gmail.com]
Sent: Wednesday, March 23, 2016 3:40 PM
To: user@cassandra.apache.org
Subject: Re: Rack aware question.
> How come 127.0.0.1 is shown as an endpoint holding the ID when its token
> range doesn’t cont
his ever, I’d think the ignore_rack flag
> should just be deprecated.
>
>
>
> *From:* Robert Coli [mailto:rc...@eventbrite.com]
> *Sent:* Wednesday, March 23, 2016 2:54 PM
>
> *To:* user@cassandra.apache.org
> *Subject:* Re: Rack aware question.
>
>
>
> Actual
want to support this ever, I’d think the ignore_rack flag should
just be deprecated.
From: Robert Coli [mailto:rc...@eventbrite.com]
Sent: Wednesday, March 23, 2016 2:54 PM
To: user@cassandra.apache.org
Subject: Re: Rack aware question.
Actually, I believe you are seeing the behavior described in
rom racktest.racktable where id=1”
>
>
>
> *From:* Anubhav Kale [mailto:anubhav.k...@microsoft.com]
> *Sent:* Wednesday, March 23, 2016 2:04 PM
> *To:* user@cassandra.apache.org
> *Subject:* RE: Rack aware question.
>
>
>
> Thanks.
>
>
>
> To test what happens
Oh, and the query I ran was “select * from racktest.racktable where id=1”
From: Anubhav Kale [mailto:anubhav.k...@microsoft.com]
Sent: Wednesday, March 23, 2016 2:04 PM
To: user@cassandra.apache.org
Subject: RE: Rack aware question.
Thanks.
To test what happens when rack of a node changes in a
On Wed, Mar 23, 2016 at 8:07 AM, Anubhav Kale
wrote:
> Suppose we change the racks on VMs on a running cluster. (We need to do
> this while running on Azure, because sometimes when the VM gets moved its
> rack changes).
>
> In this situation, new writes will be laid out based on new rack info on
I could be wrong on this since I've never actually attempted what you are
asking. Based on my understanding of how replica assignment is done, I
don't think that just changing the rack on an existing node is a good idea.
Changing racks for a node that already contains data would result in that
dat
Hello,
Suppose we change the racks on VMs on a running cluster. (We need to do this
while running on Azure, because sometimes when the VM gets moved its rack
changes).
In this situation, new writes will be laid out based on new rack info on
appropriate replicas. What happens for existing data
12 matches
Mail list logo
