Project re-index in Jira
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs 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
Summary
In Jira Data Center, you have several options for re-indexing, as outlined in Search indexing. This article gives some background on the single-project re-index.
Solution
When the 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 trigger a local re-index of the entity. It 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:
no versions in index snapshot during full re-index: JRASERVER-72944 - Restoring an index snapshot after a full re-index might trigger the index fixer, delaying the node start up
unreliable index snapshot exchange: JRASERVER-72125 - Index replication service is paused indefinitely after failing to obtain an index snapshot from another node
When doing a large project re-index (in Jira 9.x ) a full foreground re-index should be recommended.
Resources
Was this helpful?