gt;>
>> From: Avi Kivity <a...@scylladb.com <mailto:a...@scylladb.com>>
>> Sent: Wednesday, January 17, 2018 2:50 PM
>> To: user@cassandra.apache.org <mailto:user@cassandra.apache.org>; kurt
>> greaves
>> Subject: Re: vnodes: high availability
>&
addad.com>
Sent: Thursday, January 18, 2018 12:49:02 AM
To: user
Subject: Re: vnodes: high availability
I *strongly* recommend disabling dynamic snitch. I’ve seen it make latency
jump 10x.
dynamic_snitch: false is your friend.
On Jan 17, 2018, at 2:00 PM, Kyrylo Lebediev
<kyrylo_le
;a...@scylladb.com>
> Sent: Wednesday, January 17, 2018 2:50 PM
> To: user@cassandra.apache.org; kurt greaves
> Subject: Re: vnodes: high availability
>
> On the flip side, a large number of vnodes is also beneficial. For example,
> if you add a node to a 20-node cluster with ma
From: Avi Kivity <a...@scylladb.com>
Sent: Wednesday, January 17, 2018 2:50 PM
To: user@cassandra.apache.org; kurt greaves
Subject: Re: vnodes: high availability
On the flip side, a large number of vnodes is also beneficial. For example, if
you add a node to a 20-node cluster with many
a selection of items from a collection, such
that (unlike permutations) the order of selection does not matter.
From: kurt greaves <k...@instaclustr.com>
Sent: Wednesday, January 17, 2018 5:43:06 AM
To: User
Subject: Re: vnodes: high availability
Even with a lo
dad <jonathan.had...@gmail.com
<mailto:jonathan.had...@gmail.com>> on behalf of Jon Haddad
<j...@jonhaddad.com <mailto:j...@jonhaddad.com>>
*Sent:* Tuesday, January 16, 2018 8:21:33 PM
*To:* user@cassandra.apache.org <mailto:user@cassandra.apache.org>
*Subject:* Re: vnode
rship. It should be possible to improve dramatically on
> this with deterministic ...
>
> --
> *From:* Jon Haddad <jonathan.had...@gmail.com> on behalf of Jon Haddad <
> j...@jonhaddad.com>
> *Sent:* Tuesday, January 16, 2018 8:21:33 PM
>
> *To:* user
Haddad <jonathan.had...@gmail.com> on behalf of Jon Haddad
<j...@jonhaddad.com>
Sent: Tuesday, January 16, 2018 8:21:33 PM
To: user@cassandra.apache.org
Subject: Re: vnodes: high availability
We’ve used 32 tokens pre 3.0. It’s been a mixed result due to the randomness.
There’s going to
Kyrill
> From: Jon Haddad <jonathan.had...@gmail.com> on behalf of Jon Haddad
> <j...@jonhaddad.com>
> Sent: Tuesday, January 16, 2018 6:44:53 PM
> To: user
> Subject: Re: vnodes: high availability
>
> While all the token math is helpful, I have to also call ou
et some links to calculations of C* reliability based on which
decisions were made.
Regards,
Kyrill
From: kurt greaves <k...@instaclustr.com<mailto:k...@instaclustr.com>>
Sent: Tuesday, January 16, 2018 2:16:34 AM
To: User
Subject: Re: vnodes: high availability
to calculations of C* reliability based on which
> decisions were made.
>
> Regards,
> Kyrill
> From: kurt greaves <k...@instaclustr.com>
> Sent: Tuesday, January 16, 2018 2:16:34 AM
> To: User
> Subject: Re: vnodes: high availability
>
> Yeah it's very un
ordinator node as the request has specified via the...
From: Alexander Dejanovski <a...@thelastpickle.com>
Sent: Tuesday, January 16, 2018 12:50:13 PM
To: user@cassandra.apache.org
Subject: Re: vnodes: high availability
Hi Kyrylo,
high availability can
links to calculations of C* reliability based on which
> decisions were made.
>
>
> Regards,
>
> Kyrill
> --
> *From:* kurt greaves <k...@instaclustr.com>
> *Sent:* Tuesday, January 16, 2018 2:16:34 AM
> *To:* User
>
> *Subject:* R
From: kurt greaves <k...@instaclustr.com>
Sent: Tuesday, January 16, 2018 2:16:34 AM
To: User
Subject: Re: vnodes: high availability
Yeah it's very unlikely that you will have 2 nodes in the cluster with NO
intersecting token ranges (vnodes) for an RF of 3 (probably even 2).
I
>
> How would the situation differ from this example by DataStax, if we had a
> real-life 6-nodes cluster with 8 vnodes on each node?
>
>
> Regards,
>
> Kyrill
>
>
> --
> *From:* Alexander Dejanovski <a...@thelastpickle.c
de?
Regards,
Kyrill
From: Alexander Dejanovski <a...@thelastpickle.com>
Sent: Monday, January 15, 2018 8:14:21 PM
To: user@cassandra.apache.org
Subject: Re: vnodes: high availability
I was corrected off list that the odds of losing data when 2 no
| grep -B2
>> -A2 '' | grep -v '' | grep -v '^--' | sort |
>> uniq | wc -l
>>
>> returned number which equals to Nnodes -1, what means that I can't switch
>> off 2 nodes at the same time w/o losing of some keyrange for CL=QUORUM.
>>
>>
>> Thank
h equals to Nnodes -1, what means that I can't switch
> off 2 nodes at the same time w/o losing of some keyrange for CL=QUORUM.
>
>
> Thanks,
>
> Kyrill
> --
> *From:* Rahul Neelakantan <ra...@rahul.be>
> *Sent:* Monday, January 15, 2018
me w/o losing of some keyrange for CL=QUORUM.
Thanks,
Kyrill
From: Rahul Neelakantan <ra...@rahul.be>
Sent: Monday, January 15, 2018 5:20:20 PM
To: user@cassandra.apache.org
Subject: Re: vnodes: high availability
Not necessarily. It depends on h
Not necessarily. It depends on how the token ranges for the vNodes are
assigned to them. For example take a look at this diagram
http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/architecture/architectureDataDistributeDistribute_c.html
In the vNode part of the diagram, you will see
Hi,
Let's say we have a C* cluster with following parameters:
- 50 nodes in the cluster
- RF=3
- vnodes=256 per node
- CL for some queries = QUORUM
- endpoint_snitch = SimpleSnitch
Is it correct that 2 any nodes down will cause unavailability of a keyrange at
CL=QUORUM?
Regards,
21 matches
Mail list logo
