Disaster recovery setup

[Swetha Bammidi]

Hi,

I wanted to setup disaster recovery with 2 nodes(one is Master and other one as slave) without clustering

As of now i have completed below steps:

Mysql Replication:

• Installed mysql database on both nodes and changed setting in my.cnf and created user for replication on mysql master node.
• Changed setting on slave node in my.cnf
• Taken dump from on Master node.
• Configured replication settings on slave node.

Installed JIRA on master node and connected with the master database.

Copied JIRA installation and data directories from master node to slave node and connected with the replication database.

Started JIRA on master node and whatever i customize in this it is getting replicated in both databases(master and slave databases) but these changed are not getting reflected in slave node JIRA .

What is the next step to configure disaster recovery.

Thanks,

swetha

[Nic Brough -Adaptavist- · Accepted solution]

You must not run the slave JIRA while the master is active and replication is running.

Shut it down and leave it alone.  To test changes, break replication and restart the slave JIRA, you should find it's working fine then, although you will want to re-index it before any real testing.  Once you've checked everything, shut it down again and re-enable replication (losing the changes you made during testing)

[FlorinM]

To add to Nic's answer, you probably also need to replicate some parts of the JIRA_HOME folder, like JIRA_HOME/data (for attachments, avatars and other icons) and JIRA_HOME/plugins

[DerivcoITServer]

Hi,

Just to share my experience thus far as well with this.  I have jira, confluence and fisheye/cruiclble, each on their own linux application servers, with a central postgres database server hosting all the databases.

I have setup master slave replication on the database server.  I have installed each application on the slave application servers RSyncing the content of the home and install directories from the master to the slaves.  All the slave application services are disabled and are not started.  

In the case of recovery we would need to failover all our applications(Jira, Confluence and Fisheye) to the slaves.  The process will be the following:

1. Shutdown the confluence, jira and fisheye application services on the master services.
2. Stop database replication.  This stops the replication for all Atlassian databases on this instance.
3. Stop RSync jobs from master to slave that syncs the application and install data.
4. Update all the slave instances to now be the primary. 
5. Update database connection to slave database server.
6. Startup the slave application services.
7. Update DNS entries.

The reason for failing over all our application servers is because of the database replication.  If we had to recover by moving back to our master instances we would just need to sync the databases and applications back to the master servers again from the slaves. 

Would we be better of, instead of having to fail over all our applications, just to fail over the problematic application? This would mean each database for each application we hosted on seperated database servers ?

Our master and slave servers are hosted on different geographic locations.  Would this be a problem with latency since all the 3 applications are tightly integrated?

Regards,

Avinash

[DerivcoITServer]

Any thoughts on the above ?

Another question...

For confluence as an example would it be possible  to have the same scenario as above, where the database is replicated and the home and installed folders as well, but this time we want the slave confluence server running in read only mode. We can do this by applying an expired licence.   Will it be ok having both the master and slave applications running at the same time?

I was thinking of the approach as a means of if our master environment breaks for some reason, users can access their content from the slave instance(in readonly mode) while we try recover the master.