We are currently hosting a little over 80 projects on our JIRA 5.2.4 instance.
We understand the re-index recommendations that are triggered by JIRA when a major configuration change has been made to one of our projects, such as a change to a Custom Field, Field Configuration Scheme or plugin, but is there an Atlassian recommended frequency or standard for re-indexing JIRA as part of a regular maintenance routine even if there were not any major changes made to any of the 80+ projects?
Does the number of projects hosted on a single JIRA instance warrant a regularly scheduled re-index or is the re-index only needed when a major change is made to one or some of the projects?
Thanks for your support,
Yes and no.
My experience with Jira is from the latest release of 2 (my first task was an upgrade to 3.0.3), and even with version 3, the answer is the same - you should NOT need to re-index automatically. I'm really not sure Janet's answer is strictly correct, because I don't remember ever seeing advice to index for no reason other than "we haven't done it for a while", but maybe I missed something.
I've run Jira 3.x installations for months (in one case, years) without needing to re-index and only ended up doing it because I've run into a specific reason to do so.
In all versions, there are things where you do need to re-index. The obvious one is if you change the searcher for an issue - that can leave your index "wrong" for the field. There are others of course, and Jira does now suggest it when it thinks you need to reindex.
In real life though, there are all sorts of things that can go wrong. Basically, if at any time, Jira is not shut down "cleanly", it can damage the index. You can provoke index errors by overloading the server, and there's other transient errors that may creep in on a complex Jira system. Also, my absolute favourite as it's a very common way to damage an index - plugins written by people who don't know the internals of Jira well enough (most spectacular ones are those who write code that changes the end-point of a transition - never seen that fail to corrupt your index). I should add - I am one of those coders, I've written code that's broken an index more than once.
So, in theory, the answer is "No". Don't index regularly, it's simply not needed. Index when you actually need it. In the real world, if you are seeing problems, then it may well be worth regularly re-indexing until you can chase down and fix those problems permanently.
One reason we need to reindex is due to custom scripted fields via Script Runner.
On Epics, we have rollup fields (e.g., Story Points) calculated based on other issues. Changes to those issues never trigger an automatic reindex on the Epic (which we want to see in search results in Confluence).
So we are programmatically trying to reindex based on certain fields updates. But that still does not cover the case where the Epic-issue links are changed (which does not throw any events). For that we figure we have to settle for a scheduled type of reindex (perhaps Script Runner Escalation Service "Additional Code").
In older version like JIRA 3.13.x , the scheduled re-indexing as part of the maintainance task was recommended. However, the re-indexing architecture of JIRA has improved since then and it has become an unneccessary maintainance task.
In the recent version including JIRA 5.2.4 , it is unneccesary to re-index JIRA unless there is major changes has been made or the indexes has been corrupted,deleted etc due to other factors. Thus, there is no recommended frequency based on time or size of the instance.
P/s: You may run the re-indexing in your maintainance routine if you would like to ;)
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG