This is not a good answer. Some JIRA instances, including ours, serve 10k users or more and experience hundreds of changes a week across hundreds of projects. Many of these changes call for a reindex.
One challenge is that background reindexing can take double or triple the time of a hard (locking) reindex, and is less efficient. When Background reindexing takes more than twelve hours, creeping into daytime hours on a system already struggling for resources, it's time to more regularly do a hard reindex - e.g. weekly - and this is why I am up right now, on a Saturday night.
BTW, we moved to Data Center late last year. While keeping indexes in sync is sometimes a problem in JIRA 7 - JIRA 8 is reputedly much better at this - if you do a hard (locking) reindex on one node (app server), and have your load balancer set up properly, users are bounced to other nodes.
Then, after the first node is reindexed, from the indexes admin page on the other nodes you can "pull" indexes from that other node. No need to individually reindex each, or to wait for eth changes to eventually tricle over from that reindexed node (they might not, or not in time), or to down all nodes and manually dupe the good index directory over as I have done after upgrades before.
The reason for not having an automatic may be understandable, but the explanation provided is not the best one, in my opinion. I'm pretty surprised that this is considered the correct answer.
There are a lot of changes inside instances having tens/hundreds of projects combined with hundreds/thousands of custom fields everything in million of tickets, and any changes made manually on them, could affect the indexes, as the index pop out warning suggests, especially after changes on CFs/Fields Configuration. Most of the big instances requires for periodical background reindex and even periodical full-reindex.
While I can understand that full-reindex blocks UI JIRA usage, the background reindex can, and sometimes should be, scheduled during weekends, since that action shouldn't require human interaction, and would harm no one, comparing to running it during weekedays, when people are working. As you are aware, CPU is highly increased during reindex procedure, so I believe that an automation would help for this case. In our case a JIRA background reindex takes 17 hours, and our users cover at least 7 timezones.
Yes, we know that it can be done via API or groovy scripting, but again, I do not believe that this is the best answer to be accepted by Atlassian.
I agree with Kay - my reindex takes over 1 hour due to the sheer size of our platform. I have to say i get a little tired of the Atlassian Point of View that says i must do this manually, in my own time out of hours on a platform with a number of homeworkers and international staff who want a lot of access hours.
This forces me to sit up at 10pm at night and hang around. That's a little ridiculous. I should be able to set something on the working day that will trigger it at Xhours and just leave a system banner to communicate that it will be coming down later.
Atlassian have said they want to be considered *an enterprise scale tool*, but these residual "small system" mentality failings that are becoming a blocker for us.
I accept your answer.
However, the reason we need to do it as we have on-going problems with the Epic link being populated into subtasks on auto create of subtasks. We are on an older version so hopefully this problem is resolved in the newer version when we upgrade shortly.
Also, re-indexing is not actually that long a job on our system.
Under normal circumstances having to automate a re-index is usually indicative of a deeper problem.
For us this is not the case....we are already on data center, but we have over 300,000 issues in flight at any given time. When we import data into our eazyBI reporting platform we are finding random anomalies with the issue counts, statuses, etc. For this specific use case an automated re-index prior to an eazyBI import seems to resolve these anomalies.
Don't automate the problem away if you are seeing red indexing toaster messages.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events