Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Jira DC DRC - multiple shared homes

SEBtheSaviour
Contributor
April 4, 2023

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?

1 answer

0 votes
Neel
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 23, 2026

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

  1. Primary site: 1+ active nodes sharing the same shared home + primary database

  2. File replication (rsync/storage-level replication) copies shared-home content to a secondary location

  3. Use your DB vendor's native replication (e.g., PostgreSQL streaming replication, Oracle Data Guard) for db replication

  4. 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!

Suggest an answer

Log in or Sign up to answer