Expanding on number 4 below: I'm not quite sure what the easiest course of action might be. Currently the 4 existing nodes listen on private IPs and seeds are set to internal DNS names. Is setting broadcast_address to their public IPs and restarting a viable solution?
I'm trying to minimize changes to the existing DC, if that means Amazon charges me for transferring data via public IPs, so be it. On Wed, Jun 26, 2019, 10:19 AM Voytek Jarnot <voytek.jar...@gmail.com> wrote: > I started an higher-level thread years ago about moving a cluster by > expanding from 1 to 2 datacenters, replicating over, then decommissioning > the original DC. Corporate plans being what they are, we're finally getting > into this; I'm largely following the writeup here: > https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/operations/opsAddDCToCluster.html > , > but have a few more-specific questions: > > current setup: 1 DC, 4 nodes, RF=3, 1 keyspace > new DC will be 4 nodes as well, RF=3 > > 1) We currently have 2 seed nodes, I'd like to confirm that the correct > course is to make 1-2 (let's say 2) of the new-DC nodes seeds as well, and > update all nodes in both DCs to point at all 4 seeds before I get into > altering the keyspace. > > 2) Prior to altering the replication on my keyspace to include the new DC, > I do not need/want to create the keyspace in the new DC, correct? > > 3) The datastax docs mention the auto_bootstrap=false setting, but don't > go into much detail - I'm leaning toward setting it to false on all the new > nodes, sound reasonable? > > 4) One of the three environments in which this'll happen is slightly more > complicated due to the existing DC living in AWS, whereas the new DC will > be in a different AZ. Do I need to get into switching > from GossipingPropertyFileSnitch to Ec2MultiRegionSnitch? If so, could > someone shed a bit of light on that process, and the associated changes > needed for listen_address and broadcast_address? > > Thanks for getting this far, > Voytek Jarnot >
