I am creating the cluster in Marklogic AWS AMi instance.I initiated the host successfully and added the node to the Cluster. After that , I had verified the host status from the Node-1 Admin UI and its connected . However when i am accessing the url (http://node-2:8001) from the browser , i am getting the 504 error from the browser response. When i verified the logs /var/opt/marklogic/Logs/Errorlog.txt -node2 , i had seen the following error from the error logs.
ErrorLog.txt:2018-11-06 15:46:55.007 Error: AppRequestTask::run:XDMP-
WRONGHOST: Host 17757088108171649752(marklogic-node1) thinks it is
really host 6376803667935202073(marklogic-node2)
I am not really sure why i had this error and did not find any thing from the documentation other than xdmp:wrong-hsot message. Could some one provide some insight why i got the error and how to resolve it .
Somewhere along the line you ended up with either the DNS for 'marklogic-node1' and 'marklogic-node2' inconsistent when resolved on either host, or some portion of the configuration from node1 onto node2 (or visa versa).
Where did you get the AMI to create node2 ? If you got this by creating an image off an existing ML node you will run into this kind of problems. Similarly if you copy any of the data between them, or change hostnames or IP addresses after the first launch of MarkLogic on a given host.
You can also end up like this if you are re-configing what was a managed-cluster without following the docs, and/or create a an AMI from such a cluster and use it elsewhere.
In general: * All OS level configuration should be done before ML is started for the first time on any server
AMI's should be 'clean' -- not made from a previous installation
Managed Cluster hosts should only be updated, added to or removed from clusters using the documented external programs.
The hostname that the OS uses should match the hostname you supply to ML and should match the DNS resolution -- and should resolve identically on all hosts in a cluster.
Hosts should be attached directly to each other not through load balancers or proxies.
There are ways around these generalizations, but they require significant knowlege to get right.