cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Cameron <jus...@instaclustr.com>
Subject Re: token distribution in multi-dc
Date Wed, 03 May 2017 01:12:23 GMT
Thanks for the correction Sebastian.

I guess I didn't think that through too clearly myself before replying, as
I know it's not possible to have two nodes in a cluster with the same token.

On Wed, 3 May 2017 at 11:03 Sebastian Estevez <
sebastian.estevez@datastax.com> wrote:

> Hi Justin,
>
> > each DC will have a complete token ring
>
> This statement--and the diagram--imply that you can have multiple nodes
> with the same token as long as they are in seperate DCs. This isn't the
> case, though I understand how it is easy to fall into that trap.
>
> To help reason about this consider the following:
>
> If you could have two nodes (even across DC's) with the same token (T),
> how would you determine the primary replica for a global consistency level
> query that hashes to that token (T) +1? How would you calculate the ranges
> for a global range repair?
>
> You can either view ranges within a datacenter (for local queries and
> local repairs) or you can view ranges cluster wide (for global queries and
> global repairs). It is also useful sometimes to think of two DC's as two
> rings, we draw them like that all the time. However, there is really only
> one ring (to rule them all) which means token collisions are not allowed.
>
> > setup with V-nodes enabled
>
> Fortunately Vasu's configuration uses vnodes and so it doesn't really
> matter. The vnode allocation algorithm will ensure that there are no
> collisions. Unless you are hardcoding your vnode tokens in the yaml
> manually, in which case I'd be curious to understand why.
>
>
> All the best,
>
>
> Sebastián
>
>
>
>
> On Tue, May 2, 2017 at 8:45 PM, Justin Cameron <justin@instaclustr.com>
> wrote:
>
>> That's correct - each DC will have a complete token ring. You can think
>> of a Cassandra data center as effectively it's own self-contained
>> "mini-cluster". See diagram below (diagram assumes RF3 in both DCs and a
>> token range of only 0-99 for readability).
>>
>> [image: 2dc.png]
>>
>> On Wed, 3 May 2017 at 08:07 vasu gunja <vasu.nosql@gmail.com> wrote:
>>
>>> I'm confused now. please someone confirm with proof.
>>>
>>> On Tue, May 2, 2017 at 4:54 PM, vasu gunja <vasu.nosql@gmail.com> wrote:
>>>
>>>> In that case there will be duplication of tokens ranges will present
>>>> cluster right ?.
>>>> Please prove
>>>>
>>>>
>>>> On Mon, May 1, 2017 at 7:54 PM, Justin Cameron <justin@instaclustr.com>
>>>> wrote:
>>>>
>>>>> Hi Vasu,
>>>>>
>>>>> Each DC has a complete token range.
>>>>>
>>>>> Cheers,
>>>>> Justin
>>>>>
>>>>> On Tue, 2 May 2017 at 06:32 vasu gunja <vasu.nosql@gmail.com> wrote:
>>>>>
>>>>>> Hi ,
>>>>>>
>>>>>> I have a question regarding token distribution in muti-dc setup.
>>>>>>
>>>>>> We are having multi-dc (DC1+DC2) setup with V-nodes enabled.
>>>>>> How token ranges will be distributed in cluster ?
>>>>>>
>>>>>> Is complete cluster has completed one token range ?
>>>>>> Or each DC has complete token  range?
>>>>>>
>>>>>>
>>>>>> --
>>>>>
>>>>>
>>>>> *Justin Cameron*Senior Software Engineer
>>>>>
>>>>>
>>>>> <https://www.instaclustr.com/>
>>>>>
>>>>>
>>>>> This email has been sent on behalf of Instaclustr Pty. Limited
>>>>> (Australia) and Instaclustr Inc (USA).
>>>>>
>>>>> This email and any attachments may contain confidential and legally
>>>>> privileged information.  If you are not the intended recipient, do not
copy
>>>>> or disclose its content, but please reply to this email immediately and
>>>>> highlight the error to the sender and then immediately delete the message.
>>>>>
>>>>
>>>>
>>> --
>>
>>
>> *Justin Cameron*Senior Software Engineer
>>
>>
>> <https://www.instaclustr.com/>
>>
>>
>> This email has been sent on behalf of Instaclustr Pty. Limited
>> (Australia) and Instaclustr Inc (USA).
>>
>> This email and any attachments may contain confidential and legally
>> privileged information.  If you are not the intended recipient, do not copy
>> or disclose its content, but please reply to this email immediately and
>> highlight the error to the sender and then immediately delete the message.
>>
>
> --


*Justin Cameron*Senior Software Engineer


<https://www.instaclustr.com/>


This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
and Instaclustr Inc (USA).

This email and any attachments may contain confidential and legally
privileged information.  If you are not the intended recipient, do not copy
or disclose its content, but please reply to this email immediately and
highlight the error to the sender and then immediately delete the message.

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message