Change Location of indexes on Jira Core server setup.

[bogdan_radu_sv]

I'm looking to change the Location of indexes on my Jira Core 8.5.1 install, but the Jira manual is not very specific on how to do it. I searched for it but the solutions don't seem to fit.

I found a solution in which you search the DB and change inside it but there is nothing inside my DB. I want to change the path from /var/atlassian/jira/caches/indexesV1 to another location.

thanks

[Nic Brough -Adaptavist-]

You can't change it in the software, it's always going to be <jira home>/caches

You can do it with the operating system though - you can mount a different disk under <jira home>/caches, or replace the directory with a symbolic link to another place.  As long as what you do looks like a directory to the Jira system, it will work fine.

(One note of caution - do not put the index on shared storage - it will fail)

[Joey Officer]

Can you expand on the failure - is it jus that the index will (potentially?) become unavailable/unhealthy throughout the day and a re-index resolves the issue?

I recently migrated our Jira installation directory from one system to another and the intent was to put the jira-home directory on NFS (mostly for backup/snapshotting reasons) but did receive the warning.  I could indeed create a symlink to another 'local' directory, but before I get too far down that path, what is the exposure for using NFS as part of the index directory?

[Nic Brough -Adaptavist-]

Don't do it. 

There are bits of the home directory that are fine on shared storage, and if you skim the Data-Center docs about it, you'll see which ones because DC relies on shared storage for some of it (Attachments, for example)

There are two big problems you would find - performance and corruption.

Your database is "the source of truth" (plus the attachments directory), so it is very unlikely that you would lose data (but I can't completely rule it out - I have seen two cases where a corrupt index put bad data back into the database via a cache), but a corrupt index means inaccurate searches and reporting.

An index on an NFS disk can put a massive dent in your performance (I would use the word "decimate", but most people don't know that it means a 10% cut, and I need a word that means "the other 90%").  I first saw it on a system where people complained that viewing an issue and the admin screens worked fine, but they were waiting for 2-3 minutes for searches, dashboards, boards, and reports to render.

And the index is highly vulnerable to corruption when on NFS, which means inaccuracy in the places I mentioned above.

Yes, re-indexing will fix the corruptions, but you have the problem that you need to run the full locking re-index which locks all your users out to get a fully repaired one. 

If your re-index is a minute (it won't be on NFS, even for a small Jira), that's not so much of a problem, but if it's hours, you're losing hours of usage a day, and on top of that, even running a re-index can create corrupt data, so as soon as you finish, you might need to run another one.

[Joey Officer]

Thanks Nic, you have thoroughly put the fear of corruption in me and I will ensure the indexes are not stored on NFS.

[Adrian Stephen]

Hi @bogdan_radu_sv 

This is not possible as documented here 

• https://confluence.atlassian.com/adminjiraserver/search-indexing-938847710.html

If you upgraded Jira with an XML backup from a Jira version prior to 4.2 and used a custom directory for your index path, you can choose between using this custom directory (which cannot be edited) or the default directory for your index path location. However, once you switch to using the default directory, you can no longer choose the custom directory option.