I will heavy lift the docs for a while, do my Slender Cassandra reference project and then I’ll try to find one or two areas where I can contribute code to get going on that. I have read the section on contributing before I start. I’ll self-assign the JIRA right now.
Kenneth Brotman From: Jonathan Haddad [mailto:j...@jonhaddad.com] Sent: Thursday, February 22, 2018 1:21 PM To: user@cassandra.apache.org Subject: Re: Initializing a multiple node cluster (multiple datacenters) Kenneth, if you want to take the JIRA, feel free to self-assign it to yourself and put up a pull request or patch, and I'll review. I'd be very happy to get more people involved in the docs. On Thu, Feb 22, 2018 at 12:56 PM Kenneth Brotman <kenbrot...@yahoo.com.invalid> wrote: That information would have saved me time too. Thanks for making a JIRA for it Jon. Perhaps this is a good JIRA for me to begin with. Kenneth Brotman From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad Sent: Thursday, February 22, 2018 11:11 AM To: user Subject: Re: Initializing a multiple node cluster (multiple datacenters) Great question. Unfortunately, our OSS docs lack a step by step process on how to add a DC, I’ve created a JIRA to do that: https://issues.apache.org/jira/browse/CASSANDRA-14254 The datastax docs are pretty good for this though: https://docs.datastax.com/en/cassandra/latest/cassandra/operations/opsAddDCToCluster.html Regarding token allocation, it was random prior to 3.0. In 3.0 and up, it is calculated a little more intelligently. in 3.11.2, which was just released, CASSANDRA-13080 was backported which will help out when you add your second DC. If you go this route, you can drop your token count down to 16 and get all the benefits with no drawbacks. At this point I would go straight to 3.11.2 and skip 3.0 as there were quite a few improvements that make it worthwhile along the way, in my opinion. We work with several customers that are running 3.11 and are pretty happy with it Yes, if there’s no data, you can initialize the cluster with auto_boostrap: true. Be sure to change any key spaces using simple strategy to NTS first, and replica them to the new DC as well. Jon On Feb 22, 2018, at 10:53 AM, Jean Carlo <jean.jeancar...@gmail.com> wrote: Hi jonathan Thank you for the answer. Do you know where to look to understand why this works. As i understood all the node then will chose ramdoms tokens. How can i assure the correctness of the ring? So as you said. Under the condition that there.is <http://there.is/> no data in the cluster. I can initialize a cluster multi dc without disable auto bootstrap.? On Feb 22, 2018 5:43 PM, "Jonathan Haddad" <j...@jonhaddad.com> wrote: If it's a new cluster, there's no need to disable auto_bootstrap. That setting prevents the first node in the second DC from being a replica for all the data in the first DC. If there's no data in the first DC, you can skip a couple steps and just leave it on. Leave it on, and enjoy your afternoon. Seeds don't bootstrap by the way, changing the setting on those nodes doesn't do anything. On Thu, Feb 22, 2018 at 8:36 AM Jean Carlo <jeanjeancar...@gmail.com <mailto:jean.jeancar...@gmail.com> > wrote: Hello I would like to clarify this, In order to initialize a cassandra multi dc cluster, without data. If I follow the documentation datastax https://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html It says * auto_bootstrap: false (Add this setting only when initializing a clean node with no data.) But I dont understand the way this works regarding to the auto_bootstraps. If all the machines make their own tokens in a ramdon way using murmur3partitioner and vnodes , it isn't probable that two nodes will have the tokens in common ? It is not better to bootstrap first the seeds with auto_bootstrap: false and then the rest of the nodes with auto_bootstrap: true ? Thank you for the help Jean Carlo "The best way to predict the future is to invent it" Alan Kay
