nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JIRA in a Disaster Recovery site.

Andrew Morin

Hi All,

I have read the threads concerning DR setups from different folks, Seems everyone is a little different. The database team is restoring my production (SQL 2008) database to the DR site every night at an established time. I am just finishing up my installation so I will see how that goes tonight. My question is myshould I shut down JIRA while the restore is happening? They said they are dropping all connections but that does not give me a good feeling...will JIRA puke either way? I was planning on killing the serice and the restarting when the window closes. Down time is irrelevent until a tornado or earthquake hits Denver. Well we are at the end of a runway that has some good size planes from time to time..I digress..any thoughts would be appreciated. (Running JIRA on Windows 2008 R2 server)

Thanks

Andrew

Accepted answers

All comments

Timothy

The database team is restoring my production (SQL 2008) database to the DR site every night

Hmm, why is there a restore every night? That is just so weird that you are restoring a production every night.

They said they are dropping all connections but that does not give me a good feeling

Yes, JIRA will really vomit into the logs if the connection is not avaialble. If you are doing a restore from the backend, the application should really be shut down.

Timothy

Nic Brough -Adaptavist-

That sounds like a very weak way to do DR for Jira. Surely you would be far better off simply replicating the database, rather than stopping and rebuilding? Live data, in place, maximum data loss is a couple of seconds rather than a whole day, automatic and much easier.

Whatever your DR situation is, you wouldn't have the fail-over Jira running either, so it wouldn't actually matter what you were doing with the database.

PhilB

Seems to me that it all depends on your DR requirements. Are you required to have a hot DR failover configuration or can the DR be on cold stand-by?

If you're restoring the database only on a nightly basis then that sounds like more of a cold-standby arrangement in which case, why not just leave the Jira service on the DR site down until a disaster happens and bring it online at that point. No reason to even have it running unless there's a disaster.

There are also some product available that can detect a primary outage and bring the DR site online automatically if an outage at the primary is detected. This, again, eliminates the need to have the DR Jira Instance running unless/until a disaster actually occurs.

Harry Chan5

This is DR, it's meant to be offsite. It's equivalent of taking daily backups offsite. No problems there.

Harry Chan5

In theory DR should be a completely separate instance far off site. It assumes that a storm or something kills the entire area where the production cluster / cold failover exists.

I assume the OP has production as a cluster to do the replication you've mentioned for production already though.

Nic Brough -Adaptavist-

Erm, yes, you replicate to a DR instance far off-site. Why would you bother fiddling around reloading a day-old copy every day when you can simply replicate over a few hundred miles? I'm thinking of the UK, where London based organisations replicate to Manchester, Edinburgh, Newcastle and so-on, as well as the local replication in case of local database server failure. Rebuilding from a regular backup is for building test systems, not DR.

Harry Chan5

Firewall rules and security policies can potentially stop a replicated DR being setup. A lot of places don't allow bi-directional communication to internal networks. Log shipping may / may not work and can have issues, so this might be a solution.

We're all speculating though and there is a use case for everything. I just wouldn't say what the OP is doing is wrong without further details.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration