You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Guys,
This is a pure discussion about deployment of DR for JSM.
Previously, I was trying the solution in link https://confluence.atlassian.com/enterprise/disaster-recovery-guide-for-jira-692782022.html, but I found the whole process is quite complicated. Consequently, I tried another procedure according to my own environment:
We have a PostgreSQL cluster bundled via Consul and Patroni (3 postgresql instances, one is primary and the other two are replicas, only the primary is R/W). In the production site, I deploy the JSM connecting to the PostgreSQL via HAproxy, it is working fine so far. And in the DR site, I installed another instance of JSM without bringing it up. This is the initial(maybe normal in the future) status.
In this experiment, I copy the dbconfig.xml to the DR site and shut down the production JSM manually, then start the JSM in DR, it is up and running. Since the data is retrieved from the same datbase, all system level configuration is identical, including base URL, system id and so on (for now I have to modify the base URL for further access since there is no DNS or LB configured in the very front).
What I am concerning about now is how could I sync those files generated/installed in production site (such as attachments, avatars and installed plugins. I uncheck the index snapshots as I would like to run a full re-index once the failover is done) to the DR site, I tried the Replication function and indeed it would copy those files to the secondary site (I tried NFS, the permission part almost killed me) but the files are too scatterred to sync back to the expected directory in DR.
Your suggestion would be much appreciated and I will try it out in my lab then.
Thanks.
Jason Du
"What I am concerning about now is how could I sync those files generated/installed in production site (such as attachments, avatars and installed plugins. I uncheck the index snapshots as I would like to run a full re-index once the failover is done) to the DR site, I tried the Replication function and indeed it would copy those files to the secondary site (I tried NFS, the permission part almost killed me) but the files are too scatterred to sync back to the expected directory in DR. "
Maybe you shouldn't.
So your <atl-home>/shared directory should be where everything lives bar installed plugins (and they should re-download). Attachments and Avatars should be in /shared and I believe a copy of plugins should be there.
This <atl-home>/shared should be a FAST NFS share. It should be accessible from all nodes for node/failure as a common directory. With EC2 were talking an EBS share, with Azure you can do an equivalent.
However this is a DR site. Not production, DR. If I was doing DR, I would have a replication copy that is 1 month older then production of the NFS share with a monthly/yearly archive, why
RANSOMWARE.
The biggest call on DR is most likely a hacker, particularly when you are talking Cloud (not cloud security but someone hacking a workstation and uploading malware on your jira tickets). When recovering to DR, I would want to know I am going to a clean environment then restoring latest.
Just food for thought.