In Jira DCE, how do the Primary nodes in the cluster know about the Standby nodes ?

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.

Thanks,

Kaushik.

 

1 answer

1 vote

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,
Kaushik.

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.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Posted Wednesday in Jira

Join our webinar: How 1B+ feature flag events helped us build the new Jira

Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...

93 views 0 1
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you