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)
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.
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.
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.
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.
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.
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
@Rachel Wright (Jira Genie), @Billy Poggi (AUG NOVA, DC), and @Dana Jansen (Confluence Queen) are just some of the folks that lead one of the world's most active Atlassian User Group (AUG)....
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!
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