Changes to index management on the Jira startup in version 9.1

Still need help?

The Atlassian Community is here for you.

Ask the community


Platform Notice: Data Center Only - This article only applies to Atlassian products on the data center platform.

Before Jira 9.1

During start-up a Jira node needs to obtain the index.

If local index exists, Jira checks how far behind the DB it is:

  • If it is less than 10%, Jira starts and assumes the node replication thread will catch up asynchronously. This could cause some issues:
    • users are allowed to access node (/status endpoint returns RUNNING) even when the index is not up to date;
    • the re-indexing triggered by the node replication thread is slow (single thread re-indexing with conditional updates), so in case of large instances the <10% index catch up could still take a long time;
  • If this is more than 10%, Jira requests any other node in the cluster to create an index. The start process continues and the node asynchronously waits for the index to be created. This could cause a number of issues described in JRASERVER-72125 - Getting issue details... STATUS and / or JRASERVER-66635 - Getting issue details... STATUS .
    Some examples:
    • there is only one active node in the cluster, so there is no other node to deliver the index
    • there is more than one node starting concurrently and starting nodes exchange empty or incorrect indexes
    • node preparing the index failed to:
      • create the index snapshot
      • send the index snapshot to shared-home
      • inform the waiting node that the snapshot was created

Before Jira 9.1 it was admin's responsibility to ensure that only one node starts at a time and that all nodes in the cluster are healthy, so that each of them can provide a healthy index snapshot. 

New in Jira 9.1

Starting from Jira 9.1 the synchronous node start-up is enforced by the application.

Index start-up procedure ensures the local index is healthy before Jira can continue start-up. Jira will not start without healthy index.

The start-up procedure is performed under a cluster lock, which guarantees that only one node at a time executes it.

The index start-up procedure:

  1. Re-index missing data if a local issue index is less than 10% behind the database. Since 9.3 the % is configurable.

  2. Load a recent index snapshot from shared-home directory if one is available.
  3. Otherwise trigger a full re-index.

  4. Make sure there is a fresh index snapshot on shared (for other starting nodes)

Learn more about troubleshooting: Failed getting index on start

Last modified on Mar 9, 2023

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.