Re: Service discovery in the Cassandra cluster

[Jon Haddad]

You’re free to supply your own Seed Provider.  The Seed provider that comes 
with cassandra needs hard coded IPs, but there’s no reason why it has to be 
that way.  

There’s a handful of ideas here: 
https://issues.apache.org/jira/browse/CASSANDRA-12627 


Feel free to experiment, and good luck.

> On May 2, 2017, at 6:48 PM, Roman Naumenko  wrote:
> 
> Service discovery (aka "note some IPs") should be part of the cluster 
> bootstrapping and management.
> 
> See for example how elastic is doing this. Or consul. Its pretty standard 
> practice these days.
> 
> --
> Roman
> 
> On Tue, May 2, 2017 at 5:08 PM Steve Robenalt  > wrote:
> Hi Roman,
> 
> I'm assuming you were intending your first statement to be in jest, but it's 
> really not that hard to startup a Cassandra cluster. The defaults are pretty 
> usable, so if all you want to do is set the IPs and start it up, the cluster 
> probably will just take care of everything else.
> 
> So I jest a little bit too. It's normally desirable to set up storage 
> properly for your database, and there's a few options for which you might 
> want to change the defaults, such as the snitch. 
> 
> Still, if that means you only need to take note of of a couple of IPs and 
> designate them as seeds so your cluster can mostly manage itself, you can say 
> that's sad, but I'd say it's a small price to pay for all that you don't have 
> to do.
> 
> Steve
> 
> On Mon, May 1, 2017 at 4:55 PM, Roman Naumenko  > wrote:
> Lol yeah, why 
> I guess I run some ec2 instances, drop some cassandra deb packages on 'em - 
> the thing will figure out how to run...
> 
> Also, how would you get "initial state of the cluster" if the cluster... is 
> being initialized? 
> Or that's easy, according to the docs - just hardcode some seed IPs into each 
> node, lol
> 
> It's all kinda funny, but in a sad way.
> 
> On Mon, May 1, 2017 at 4:45 PM, Jon Haddad  > wrote:
> Why do you have to figure out what’s up w/ them by accident?  You’ve gotten 
> all the information you need.  Seeds are used to get the initial state of the 
> cluster and as an optimization to spread gossip faster.  That’s it.  
> 
> 
> 
>> On May 1, 2017, at 4:37 PM, Roman Naumenko > > wrote:
>> 
>> Well, I guess I have to figure out what’s up with IPs/hostnames by 
>> experiment.
>> Information about service discovery is practically absent.
>> Not to mention all important details about fqdns/hostnames, automatic 
>> replacing seed nodes or what not. 
>> 
>> —
>> Roman
>> 
>>> On May 1, 2017, at 4:14 PM, Jon Haddad >> > wrote:
>>> 
>>> The in-tree docs do not mention this anywhere, and even have some of the 
>>> answers you’re asking:
>>> 
>>> https://cassandra.apache.org/doc/latest/faq/index.html?highlight=seed#what-are-seeds
>>>  
>>> 
>>> 
>>> The DataStax docs are maintained outside of the project, you’ll have to ask 
>>> them why they’re wrong or misleading.
>>> 
>>> Jon
>>> 
 On May 1, 2017, at 4:10 PM, Roman Naumenko >>> > wrote:
 
 The docs mention IP addresses everywhere.
 
 http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/operations/ops_replace_seed_node.html
  
 
 Promote an existing node to a seed node by adding its IP address to -seeds 
 list and remove (demote) the IP address of the dead seed node from the 
 cassandra.yaml file for each node in the cluster.
 
 http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/operations/ops_replace_node_t.html
  
 
 Note the Address of the dead node; it is used in step 5.
 
 http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeSingleDS.html
  
 
> Properties to set:
> num_tokens: recommended value: 256
> -seeds: internal IP address of each seed node
 
 I saw also hostnames mentioned few times, but it just makes it even more 
 confusing.
 
 —
 Roman
 
> On May 1, 2017, at 3:50 PM, Jon Haddad  > wrote:
> 
> Sure, you could use DNS.  Where does it say IP addresses are a 
> requirement?
> 
>> On May 1, 2017, at 1:36 PM, Roman Naumenko > > wrote:
>> 
>> If I understand how Cassandra nodes work, they must contain a list of 
>> seed’s IP addressed in config file.
>> 
>> This requirement makes cluster setup unnecessari

Re: Service discovery in the Cassandra cluster

[Roman Naumenko]

Service discovery (aka "note some IPs") should be part of the cluster
bootstrapping and management.

See for example how elastic is doing this. Or consul. Its pretty standard
practice these days.

--
Roman

On Tue, May 2, 2017 at 5:08 PM Steve Robenalt 
wrote:

> Hi Roman,
>
> I'm assuming you were intending your first statement to be in jest, but
> it's really not that hard to startup a Cassandra cluster. The defaults are
> pretty usable, so if all you want to do is set the IPs and start it up, the
> cluster probably will just take care of everything else.
>
> So I jest a little bit too. It's normally desirable to set up storage
> properly for your database, and there's a few options for which you might
> want to change the defaults, such as the snitch.
>
> Still, if that means you only need to take note of of a couple of IPs and
> designate them as seeds so your cluster can mostly manage itself, you can
> say that's sad, but I'd say it's a small price to pay for all that you
> don't have to do.
>
> Steve
>
> On Mon, May 1, 2017 at 4:55 PM, Roman Naumenko 
> wrote:
>
>> Lol yeah, why
>> I guess I run some ec2 instances, drop some cassandra deb packages on 'em
>> - the thing will figure out how to run...
>>
>> Also, how would you get "initial state of the cluster" if the cluster...
>> is being initialized?
>> Or that's easy, according to the docs - just hardcode some seed IPs into
>> each node, lol
>>
>> It's all kinda funny, but in a sad way.
>>
>> On Mon, May 1, 2017 at 4:45 PM, Jon Haddad 
>> wrote:
>>
>>> Why do you have to figure out what’s up w/ them by accident?  You’ve
>>> gotten all the information you need.  Seeds are used to get the initial
>>> state of the cluster and as an optimization to spread gossip faster.
>>> That’s it.
>>>
>>>
>>>
>>> On May 1, 2017, at 4:37 PM, Roman Naumenko  wrote:
>>>
>>> Well, I guess I have to figure out what’s up with IPs/hostnames by
>>> experiment.
>>> Information about service discovery is practically absent.
>>> Not to mention all important details about fqdns/hostnames, automatic
>>> replacing seed nodes or what not.
>>>
>>> —
>>> Roman
>>>
>>> On May 1, 2017, at 4:14 PM, Jon Haddad 
>>> wrote:
>>>
>>> The in-tree docs do not mention this anywhere, and even have some of the
>>> answers you’re asking:
>>>
>>>
>>> https://cassandra.apache.org/doc/latest/faq/index.html?highlight=seed#what-are-seeds
>>>
>>> The DataStax docs are maintained outside of the project, you’ll have to
>>> ask them why they’re wrong or misleading.
>>>
>>> Jon
>>>
>>> On May 1, 2017, at 4:10 PM, Roman Naumenko  wrote:
>>>
>>> The docs mention IP addresses everywhere.
>>>
>>>
>>> http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/operations/ops_replace_seed_node.html
>>> Promote an existing node to a seed node by adding its IP address to
>>> -seeds list and remove (demote) the IP address of the dead seed node from
>>> the cassandra.yaml file for each node in the cluster.
>>>
>>>
>>> http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/operations/ops_replace_node_t.html
>>> Note the Address of the dead node; it is used in step 5.
>>>
>>>
>>> http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeSingleDS.html
>>>
>>> Properties to set:
>>> num_tokens: recommended value: 256
>>> -seeds: internal IP address of each seed node
>>>
>>>
>>> I saw also *hostnames *mentioned few times, but it just makes it even
>>> more confusing.
>>>
>>> —
>>> Roman
>>>
>>> On May 1, 2017, at 3:50 PM, Jon Haddad 
>>> wrote:
>>>
>>> Sure, you could use DNS.  Where does it say IP addresses are a
>>> requirement?
>>>
>>> On May 1, 2017, at 1:36 PM, Roman Naumenko  wrote:
>>>
>>> If I understand how Cassandra nodes work, they must contain a list of
>>> seed’s IP addressed in config file.
>>>
>>> This requirement makes cluster setup unnecessarily complicated. Is it
>>> possible to use DNS name for seed nodes?
>>>
>>> Thanks,
>>>
>>> —
>>> Roman
>>> -
>>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: user-h...@cassandra.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
>
>
> * Steve Robenalt Software Architect, HighWire Press, Inc. *
> www.highwire.org| Los Gatos, CA| Belfast, NI| Brighton, UK
> 
> 
>
> *HighWire Summer Publishers' Meeting, London, June 12-13
> *
> STM Annual US Conference, April 25-27: Michiel Klein Swormink and Jennifer
> Chang are representing HighWire
> 
> 2017 CSE Annual Meeting: John Sack is presenting on topic of Piracy, May 23
> 
> SSP Annual Meeting, May 31-June 2: *Visit HighWire on Booth #101A*
> 
>
>
>
>

Re: token distribution in multi-dc

[Justin Cameron]

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.este...@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 
> 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  wrote:
>>
>>> I'm confused now. please someone confirm with proof.
>>>
>>> On Tue, May 2, 2017 at 4:54 PM, vasu gunja  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 
 wrote:

> Hi Vasu,
>
> Each DC has a complete token range.
>
> Cheers,
> Justin
>
> On Tue, 2 May 2017 at 06:32 vasu gunja  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
>
>
> 
>
>
> 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
>>
>>
>> 
>>
>>
>> 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





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.

Re: token distribution in multi-dc

[Sebastian Estevez]

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 
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  wrote:
>
>> I'm confused now. please someone confirm with proof.
>>
>> On Tue, May 2, 2017 at 4:54 PM, vasu gunja  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 
>>> wrote:
>>>
 Hi Vasu,

 Each DC has a complete token range.

 Cheers,
 Justin

 On Tue, 2 May 2017 at 06:32 vasu gunja  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


 


 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
>
>
> 
>
>
> 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.
>

Re: token distribution in multi-dc

[Justin Cameron]

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  wrote:

> I'm confused now. please someone confirm with proof.
>
> On Tue, May 2, 2017 at 4:54 PM, vasu gunja  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 
>> wrote:
>>
>>> Hi Vasu,
>>>
>>> Each DC has a complete token range.
>>>
>>> Cheers,
>>> Justin
>>>
>>> On Tue, 2 May 2017 at 06:32 vasu gunja  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
>>>
>>>
>>> 
>>>
>>>
>>> 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





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.

Re: Service discovery in the Cassandra cluster

[daemeon reiydelle]

My compliments to all of you for being adults, excessively kind, and
definitely excessively nice.


*...*



*Daemeon C.M. ReiydelleUSA (+1) 415.501.0198London (+44) (0) 20 8144 9872*

On Tue, May 2, 2017 at 5:08 PM, Steve Robenalt 
wrote:

> Hi Roman,
>
> I'm assuming you were intending your first statement to be in jest, but
> it's really not that hard to startup a Cassandra cluster. The defaults are
> pretty usable, so if all you want to do is set the IPs and start it up, the
> cluster probably will just take care of everything else.
>
> So I jest a little bit too. It's normally desirable to set up storage
> properly for your database, and there's a few options for which you might
> want to change the defaults, such as the snitch.
>
> Still, if that means you only need to take note of of a couple of IPs and
> designate them as seeds so your cluster can mostly manage itself, you can
> say that's sad, but I'd say it's a small price to pay for all that you
> don't have to do.
>
> Steve
>
> On Mon, May 1, 2017 at 4:55 PM, Roman Naumenko 
> wrote:
>
>> Lol yeah, why
>> I guess I run some ec2 instances, drop some cassandra deb packages on 'em
>> - the thing will figure out how to run...
>>
>> Also, how would you get "initial state of the cluster" if the cluster...
>> is being initialized?
>> Or that's easy, according to the docs - just hardcode some seed IPs into
>> each node, lol
>>
>> It's all kinda funny, but in a sad way.
>>
>> On Mon, May 1, 2017 at 4:45 PM, Jon Haddad 
>> wrote:
>>
>>> Why do you have to figure out what’s up w/ them by accident?  You’ve
>>> gotten all the information you need.  Seeds are used to get the initial
>>> state of the cluster and as an optimization to spread gossip faster.
>>> That’s it.
>>>
>>>
>>>
>>> On May 1, 2017, at 4:37 PM, Roman Naumenko  wrote:
>>>
>>> Well, I guess I have to figure out what’s up with IPs/hostnames by
>>> experiment.
>>> Information about service discovery is practically absent.
>>> Not to mention all important details about fqdns/hostnames, automatic
>>> replacing seed nodes or what not.
>>>
>>> —
>>> Roman
>>>
>>> On May 1, 2017, at 4:14 PM, Jon Haddad 
>>> wrote:
>>>
>>> The in-tree docs do not mention this anywhere, and even have some of the
>>> answers you’re asking:
>>>
>>> https://cassandra.apache.org/doc/latest/faq/index.html?highl
>>> ight=seed#what-are-seeds
>>>
>>> The DataStax docs are maintained outside of the project, you’ll have to
>>> ask them why they’re wrong or misleading.
>>>
>>> Jon
>>>
>>> On May 1, 2017, at 4:10 PM, Roman Naumenko  wrote:
>>>
>>> The docs mention IP addresses everywhere.
>>>
>>> http://docs.datastax.com/en/archived/cassandra/2.0/cassandra
>>> /operations/ops_replace_seed_node.html
>>> Promote an existing node to a seed node by adding its IP address to
>>> -seeds list and remove (demote) the IP address of the dead seed node from
>>> the cassandra.yaml file for each node in the cluster.
>>>
>>> http://docs.datastax.com/en/archived/cassandra/2.0/cassandra
>>> /operations/ops_replace_node_t.html
>>> Note the Address of the dead node; it is used in step 5.
>>>
>>> http://docs.datastax.com/en/cassandra/2.1/cassandra/initiali
>>> ze/initializeSingleDS.html
>>>
>>> Properties to set:
>>> num_tokens: recommended value: 256
>>> -seeds: internal IP address of each seed node
>>>
>>>
>>> I saw also *hostnames *mentioned few times, but it just makes it even
>>> more confusing.
>>>
>>> —
>>> Roman
>>>
>>> On May 1, 2017, at 3:50 PM, Jon Haddad 
>>> wrote:
>>>
>>> Sure, you could use DNS.  Where does it say IP addresses are a
>>> requirement?
>>>
>>> On May 1, 2017, at 1:36 PM, Roman Naumenko  wrote:
>>>
>>> If I understand how Cassandra nodes work, they must contain a list of
>>> seed’s IP addressed in config file.
>>>
>>> This requirement makes cluster setup unnecessarily complicated. Is it
>>> possible to use DNS name for seed nodes?
>>>
>>> Thanks,
>>>
>>> —
>>> Roman
>>> -
>>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: user-h...@cassandra.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
>
>
> * Steve Robenalt Software Architect, HighWire Press, Inc. *
> www.highwire.org| Los Gatos, CA| Belfast, NI| Brighton, UK
> 
> 
>
> *HighWire Summer Publishers' Meeting, London, June 12-13
> *
> STM Annual US Conference, April 25-27: Michiel Klein Swormink and Jennifer
> Chang are representing HighWire
> 
> 2017 CSE Annual Meeting: John Sack is presenting on topic of Piracy, May 23
> 
> SSP Annual Meeting, May 31-June 2: *Visit HighWire on Booth #101A*
> 
>
>
>
>

Re: Service discovery in the Cassandra cluster

[Steve Robenalt]

Hi Roman,

I'm assuming you were intending your first statement to be in jest, but
it's really not that hard to startup a Cassandra cluster. The defaults are
pretty usable, so if all you want to do is set the IPs and start it up, the
cluster probably will just take care of everything else.

So I jest a little bit too. It's normally desirable to set up storage
properly for your database, and there's a few options for which you might
want to change the defaults, such as the snitch.

Still, if that means you only need to take note of of a couple of IPs and
designate them as seeds so your cluster can mostly manage itself, you can
say that's sad, but I'd say it's a small price to pay for all that you
don't have to do.

Steve

On Mon, May 1, 2017 at 4:55 PM, Roman Naumenko  wrote:

> Lol yeah, why
> I guess I run some ec2 instances, drop some cassandra deb packages on 'em
> - the thing will figure out how to run...
>
> Also, how would you get "initial state of the cluster" if the cluster...
> is being initialized?
> Or that's easy, according to the docs - just hardcode some seed IPs into
> each node, lol
>
> It's all kinda funny, but in a sad way.
>
> On Mon, May 1, 2017 at 4:45 PM, Jon Haddad 
> wrote:
>
>> Why do you have to figure out what’s up w/ them by accident?  You’ve
>> gotten all the information you need.  Seeds are used to get the initial
>> state of the cluster and as an optimization to spread gossip faster.
>> That’s it.
>>
>>
>>
>> On May 1, 2017, at 4:37 PM, Roman Naumenko  wrote:
>>
>> Well, I guess I have to figure out what’s up with IPs/hostnames by
>> experiment.
>> Information about service discovery is practically absent.
>> Not to mention all important details about fqdns/hostnames, automatic
>> replacing seed nodes or what not.
>>
>> —
>> Roman
>>
>> On May 1, 2017, at 4:14 PM, Jon Haddad  wrote:
>>
>> The in-tree docs do not mention this anywhere, and even have some of the
>> answers you’re asking:
>>
>> https://cassandra.apache.org/doc/latest/faq/index.html?highl
>> ight=seed#what-are-seeds
>>
>> The DataStax docs are maintained outside of the project, you’ll have to
>> ask them why they’re wrong or misleading.
>>
>> Jon
>>
>> On May 1, 2017, at 4:10 PM, Roman Naumenko  wrote:
>>
>> The docs mention IP addresses everywhere.
>>
>> http://docs.datastax.com/en/archived/cassandra/2.0/cassandra
>> /operations/ops_replace_seed_node.html
>> Promote an existing node to a seed node by adding its IP address to
>> -seeds list and remove (demote) the IP address of the dead seed node from
>> the cassandra.yaml file for each node in the cluster.
>>
>> http://docs.datastax.com/en/archived/cassandra/2.0/cassandra
>> /operations/ops_replace_node_t.html
>> Note the Address of the dead node; it is used in step 5.
>>
>> http://docs.datastax.com/en/cassandra/2.1/cassandra/initiali
>> ze/initializeSingleDS.html
>>
>> Properties to set:
>> num_tokens: recommended value: 256
>> -seeds: internal IP address of each seed node
>>
>>
>> I saw also *hostnames *mentioned few times, but it just makes it even
>> more confusing.
>>
>> —
>> Roman
>>
>> On May 1, 2017, at 3:50 PM, Jon Haddad  wrote:
>>
>> Sure, you could use DNS.  Where does it say IP addresses are a
>> requirement?
>>
>> On May 1, 2017, at 1:36 PM, Roman Naumenko  wrote:
>>
>> If I understand how Cassandra nodes work, they must contain a list of
>> seed’s IP addressed in config file.
>>
>> This requirement makes cluster setup unnecessarily complicated. Is it
>> possible to use DNS name for seed nodes?
>>
>> Thanks,
>>
>> —
>> Roman
>> -
>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: user-h...@cassandra.apache.org
>>
>>
>>
>>
>>
>>
>>
>


-- 


* Steve Robenalt Software Architect, HighWire Press, Inc. *
www.highwire.org| Los Gatos, CA| Belfast, NI| Brighton, UK



*HighWire Summer Publishers' Meeting, London, June 12-13
*
STM Annual US Conference, April 25-27: Michiel Klein Swormink and Jennifer
Chang are representing HighWire

2017 CSE Annual Meeting: John Sack is presenting on topic of Piracy, May 23

SSP Annual Meeting, May 31-June 2: *Visit HighWire on Booth #101A*

Re: token distribution in multi-dc

[vasu gunja]

I'm confused now. please someone confirm with proof.

On Tue, May 2, 2017 at 4:54 PM, vasu gunja  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 
> wrote:
>
>> Hi Vasu,
>>
>> Each DC has a complete token range.
>>
>> Cheers,
>> Justin
>>
>> On Tue, 2 May 2017 at 06:32 vasu gunja  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
>>
>>
>> 
>>
>>
>> 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.
>>
>
>

Re: token distribution in multi-dc

[vasu gunja]

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 
wrote:

> Hi Vasu,
>
> Each DC has a complete token range.
>
> Cheers,
> Justin
>
> On Tue, 2 May 2017 at 06:32 vasu gunja  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
>
>
> 
>
>
> 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.
>