Hey guys,
I think I need a better explanation about how the secondary.shared-home works
- I put in jira-config.properties a value: disaster.recovery=true
- I put in cluster.properties where the primary shared-home is mounted (pointed to the NFS)
- I put in cluster.properties the secondary shared-home location what's basically mounted over NFS
and now:
- the primary shared-home is used properly
- the secondary shared home is synced to the primary so it's the same. It's syncing all of the time.
- as I understood the secondary shared home is located in the /jira-shared-home/secondary
- as I understood, the secondary shared home may be pointed directly to the VM B which is syncing constantly to the VM A. If that's correct?
- I cannot find a proper info if that's fine to put disaster.recovery=true along over nodes (?)
- In this scenario basically the DRC mechanism could be set in a bit different manner:
a) node A + B sharing the same (replicated) DB
b) node A uses shared-home A
c) node B uses shared-home B
d) shared-homes are fully synced to each other
with no need to put disaster.recovery=true value.
And all I would need is to cover the availability checks regarding to each node on LB?
I realise this question was asked a while ago, but I wanted to provide an answer for anyone who comes across this with a similar query.
The jira.secondary.home is a location where Jira's built-in replication copies attachments, plugins, index snapshots, and avatars from the primary shared home.
disaster.recovery=true must only be set on the standby/DR nodes (which remain stopped until failover). It changes startup behaviour so Jira recovers its index from a snapshot rather than attempting normal cluster catch-up from peers.
Your proposed scenario (at the bottom) is not supported. In a Jira DC cluster, all active nodes must share the exact same jira.shared.home (typically a single NFS mount). Giving each node its own shared home, even if externally synced, will break cluster coordination (plugin sync, cache invalidation, cluster locks) and lead to inconsistent state or data corruption.
The Supported DR Architecture for Jira DC
Primary site: 1+ active nodes sharing the same shared home + primary database
File replication (rsync/storage-level replication) copies shared-home content to a secondary location
Use your DB vendor's native replication (e.g., PostgreSQL streaming replication, Oracle Data Guard) for db replication
Standby site: 1+ stopped nodes with disaster.recovery=true, pointing to the secondary shared home + replicated database
Reference: Disaster Recovery Guide for Jira | Enterprise Data Center Latest | Atlassian Documentation
Hope that helps!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.