I am trying to follow the document but not able to understand how the Primary nodes in the cluster will understand which are the Standby nodes. We have 2 Jira nodes in cluster in Phoenix with DB and NFS synched to the NFS and DB of the 2 Jira nodes in Austin.
My question is do we have to manually enter the names of the Standby (Austin) nodes in the Primary(Phoenix nodes), as there is no configuration setting mentioned in the document.
Any suggestion or help would be appreciated.
In regards to Data Center, there is an expectation that all the nodes be in the same location. This is explained in the prerequisites section of Installing JIRA Data Center.
But to try to answer your question anyways, my understanding is that this relies upon the load balancer to determine which nodes are actually up and available for traffic. In a data center configuration, the load balanacer determines which node is selected when a new user session is attempting to be created. It does this based on the logic of what nodes are ready to serve content that it knows about.
Perhaps the guide on Jira Data Center Load Balancer examples might be helpful to understand some more details of how this can work.
Sorry for the confusion. I am trying to follow the below document
https://confluence.atlassian.com/enterprise/disaster-recovery-guide-for-jira-692782022.html for setting up Jira DR. But am not able to understand how the Primary nodes (in Phoenix) will come to know about the DR Standby Nodes (in Austin) when we start the replication.
Thanks and Regards,
The guide you cited was created a while back for Jira 6.4.x versions. While it does have steps for you to follow if you want to create a disaster recovery setup, it notes that this guide is for a cold failover configuration, not a hot failover. In a cold failover setup, the other nodes are not started at the same time as the primary node. Only when the primary node is stopped are you then expected to follow some additional administrative steps to bring the other node online.
Also that guide is expecting you to also replicate the database via some method. Since that happens, the DR nodes are also not expected to connect to the same database as the primary was connecting to. In cases like this, when the nodes in Austin are not expected to connect to the same database as the nodes in Phoenix, then those nodes then wouldn't actually be in contact at all with each other.
The database is the single source of truth in regards to your data. That guide suggests that you replicate the database, and also update the DR nodes to update to use the new database credentials.
These would be two completely separate data center deployments. But in a disaster recovery setup, that would be expected that these would be separated. Whereas if you were trying to setup a data center configuration in order to handle load/performance, then these nodes are expected to be able to communicate and reach each other unrestricted by port restrictions. In that setup, the nodes really are expected to be in the same physical location to help facilitate that configuration.
Hello folks! To the member of organizations who are still running their Atlassian applications on the server, we are on the side of the bridge, and if we need to sail the boat with confidence either...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events