That would be _most_ welcome. Glad we got this sorted out. Cheers, Adam
> On Oct 25, 2016, at 6:56 PM, Simon Keary <[email protected]> > wrote: > > > > Hi Adam, > > Thanks so much - I have a cluster working now! > > A key part I was missing was adding these lines to vm.args: > > -kernel inet_dist_listen_min 9100 > -kernel inet_dist_listen_max 9200 > > I had incorrectly assumed that these were the default settings based on the > documentation. > > I'm (obviously) very new to clustering but I'll see if I can suggest a couple > of tweaks to the documentation via a PR . > > Thanks again, > Simon > > > -----Original Message----- > From: Adam Kocoloski [mailto:[email protected]] > Sent: Wednesday, 26 October 2016 2:39 AM > To: [email protected] > Subject: Re: Node names and cluster with CouchDB 2.0 > > Hi Simon, if your nodes need to find each other by IP address you should use > -name. You can specify it in VM.args like > > -name couchdb@<the IP address> > > There shouldn't be a need to change the "couchdb@" element for each node > unless you want to run multiple nodes on the same IP (not recommended). > > When you add the peer nodes into the _nodes database you should use the same > format; each document should have an ID like "couchdb@<the IP address>". > > The firewall ports look fine provided that your vm.args file includes these > lines > > -kernel inet_dist_listen_min 9100 > -kernel inet_dist_listen_max 9200 > > Cheers, Adam > >> On Oct 25, 2016, at 1:17 AM, Simon Keary <[email protected]> >> wrote: >> >> >> >> Hi All, >> >> I'm trying to setup a test CouchDB cluster across two machines and >> struggling to get it working and understanding how the node names work. I'm >> am able to sucessfully call the _nodes endpoint on one of the machines to >> add the other but I don't think this is doing the right thing since the >> cluster_nodes array is updated with the new node but the all_nodes array >> isn't... >> >> Where I think I'm going wrong is setting the node names in the the vm.args >> files and then specifying the correct node name when trying to add the >> second machine to the first instance. In my case the machines have host >> names but neither machine can contact the other via this and can only >> contact the other via IP address. Ideally I'd only like the machines to >> connect to each other via IP and not host name as this will make maintenance >> of the cluster much simpler going forward. In this situation I'm not sure of: >> >> * Whether I should be setting -sname or -name in vm.args. When using -name, >> my testing suggests I should use a name of the form "node1" with no @ >> symbol. Is this right? >> * For -name I'm not sure whether it's supposed to be "node1@<the ip >> address>" or "node1@<the hostname>" or "node1@localhost"? >> * Once I've set the name I'm not sure how to refer to the other node when >> trying to add it via curl. If I've used -sname should I just use the short >> name (e.g. "node2") or "node2@<the ip address>"? If -name is used in vm.args >> is the correct thing to do to use "node2@<the ip address>"? >> >> I don't believe I have a connectivity issue between the nodes but the ports >> that are open between them are 4369, 5984, 5986, 9100-9200 (all TCP) and all >> UDP. >> >> When trying to remove the node, to try further variants to see if they work, >> I get an error about a document conflict. I suspect this is because CouchDB >> is getting into a strange state but this makes a trial and error process of >> figuring out how the node names work as difficult to say the least. >> >> Any help would be appreciated - Thanks! >> Simon >> >> >> >> >> Disclaimer: >> This message contains confidential information and is intended only for the >> individual(s) named. If you are not the named addressee you should not >> disseminate, distribute or copy this email. Please immediately delete it and >> all copies of it from your system, destroy any hard copies of it, and notify >> the sender. Email transmission cannot be guaranteed to be secure or >> error-free as information could be intercepted, corrupted, lost, destroyed, >> arrive late or incomplete, or contain viruses. To the maximum extent >> permitted by law, Immersive Technologies Pty. Ltd. does not accept liability >> for any errors or omissions in the contents of this message which arise as a >> result of email transmission.
