Project re-index in Jira

Related content

Still need help?

The Atlassian Community is here for you.

Ask the community

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

Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

When project re-index is triggered in Jira DC, the re-indexing process will be run on all nodes. Some details on how this works:


Local vs cluster reindex

In Jira DC there are 2 types of re-indexing:

  • local re-index - this will re-index the issue locally (re-create the lucene document) and update the local index; the meaning of this re-index operation is that nothing (the issue or the configuration) has changed so a Jira node is updating the local index without notifying all other nodes (nor via DBR nor via NodeReindexService);
  • cluster re-index - this will first bump the version of the entity (example: issue) and then triggers a local re-index of the entity, sends the lucene document to all other nodes (via DBR) and adds an entry to the index replication log to inform all nodes about this event (NodeReindexService). The meaning of this re-index is that something has changed (the issue itself or configuration) and this requires an update of indexes on all Jira nodes.


  • on the node where the project re-index was triggered a local  re-index of all issues in this project is performed 

  • this indexing operation is replicated at the project (not issue) level so a “re- index project” indexing operation entry is created in the index replication table (NodeReindexService) - DBR will not replicate this (this could cause index overload across the cluster and affect other indexing operations)

  • every other node consumes the “re-index project” indexing operation (via NodeReindexService) and triggers a local re-index of this project


Re-indexing (on both the source node and other nodes) is a single thread re-index (i.e. this is a relatively slow re-indexing process). It should not overload indexes across the cluster, but still the re-indexing operation will be run simultaneously on all nodes. 

For large projects it is usually recommended to do a full re-index on one of the nodes so other nodes can consume the project changes by getting the index snapshot produced by the node which triggered the full re-index. This approach has the following benefits:

  • the full re-index may be actually faster then re-indexing the project only as the full re-index more efficient: multithreaded, full ownership of the index so there are no conditional-updates, no risk of affecting other indexing operations
  • other nodes are not affected when the indexing is in progress - it will only be affected for a short period of time when the snapshot is be consumed
  • the node which is doing the full re-index does not accept user traffic

Note: before 9.0 this solution may be affected by 2 bugs:

When doing a large project re-index (in Jira 9.x ) a full foreground re-index should be recommended. 

Resources


Last modified on Jan 28, 2025

Was this helpful?

Yes
No
Provide feedback about this article

Related content

Powered by Confluence and Scroll Viewport.