Periodic full reindex in Jira Data Center is not required

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

Jira 8.13, Jira 8.20, Jira 9.4

Before 8.13

Before Jira 8.13, there were a number of issues in Jira that could result in inconsistency of the index between a node and the database as well as between any two nodes.

One of the main problems causing this issue was the lack of a conflict resolution algorithm when doing any update of the index. Any concurrent reindexing operation on a single issue would result in a random state of this issue in the index, which could be inconsistent with the state of the issue in the database and/or with the state of the issue on other nodes.

One way Jira Data Center admins were dealing with this problem was to schedule a regular full reindexing step into their process to fix any inconsistency. Since Jira 8.13, Jira guarantees index consistency so that performing regular full reindex can be skipped.

Users are not happy when index is corrupted.

What changed in Jira 8.13

When working on Document Index Replication, which provides almost real-time propagation of index changes across the cluster, we've introduced versioning of all indexed entities: issues, history, comments, and worklogs.

Now, every request to reindex an entity bumps this entity version, and all index updates are conditional updates. This means that a document representing an entity will only update the index if the new document version is greater than or equal to the existing document version. 

Indexing race condition solved with versioning and conditional updates.Additionally, there's a log of all indexing operations in the cluster (the database). Each node consumes this log by checking if any of the recently reindexed entities are present in the required version in the local index (the maximum delay is 15 seconds).

Find out more details on:

Known problems


Last modified on Jan 27, 2025

Was this helpful?

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