How does the JIRA database upgrade process work?

Let's say I have two JIRA servers (A, B) and their two respective database servers.  I have 6.0.6 installed on A and 6.3.13 on B.  I then duplicate A's database to B's database and point JIRA B (6.3.13) to it's new database (which contains the 6.0.6 database).  When the 6.3.13 instance of JIRA sees the 6.0.6 database on its respective database server, does it just go ahead and upgrade the database?

The reason I ask is because I'm going to install a new version of 6.3.13 on a new instance and test things out on a test database (which well then have been upgraded to 6.3.13).  Then when I am ready to migrate to the new version, can I just point JIRA 6.3.13 to a production 6.0.6 replicated database and things will just start working?




1 answer

1 vote

>When the 6.3.13 instance of JIRA sees the 6.0.6 database on its respective database server, does it just go ahead and upgrade the database


Well, that was easy wink . In reality, that answer has caveats - addons, customisations, and bugs can all break it, and badly.  But in theory, you should be able to do exactly that.  However, exactly as you say you're going to do, you really need to test it.  

Your approach is perfectly valid and it should work, but it's not the recommended approach and it is missing a step.

 The recommended approach is to run the 6.3 installer and tell it that you've got a 6.0 to upgrade.  Again, I say "in theory" because, although it should cover everything, it needs testing, every time.

The missing step if you're going to go with "install 6.3 and point it at a 6.0 database" is that you need to copy the home directory to the new installation before running it.  This is not quite as "recommended" as "run the installer", but it is very close, because the installer pretty much does the same thing in the background.

I've only done an upgrade - never a fresh install.  When I do a fresh install, is there a way for me to point it at the 6.0.3 database to tell the fresh install that it's an upgrade?

Unless I'm misunderstanding the documentation, it seems like it states to have a backup (current production) and new instance (to-be new production) and to do a fresh install on the new instance and point it to a copy of the current production database.  Then once your happy you take the new instance live and retire the old server.  So if I'm installing a fresh copy of JIRA on a new instance, it's not going to know about upgrading because there's nothing on the computer - the only way it'll "know" it's an upgrade is if there's some marker in the database that says the database was being utilized by a 6.0.3 JIRA install and needs updating...

Am I just confused? wink


>When I do a fresh install, is there a way for me to point it at the 6.0.3 database to tell the fresh install that it's an upgrade? The bad news: No, you can't (well, without a huge amount of unnecessary mucking around) The good news: You don't need to. Your idea about the database marker is right - the database contains version data. A new version reads it and goes "Oh, I need to run upgrade-data code" And your interpretation of the documentation is right, except that you've missed the point that you really should still copy over the home directory. (Actually, skip the attachments, as that really is just copy them in order to make them available, the upgrade really doesn't need them. And you can skip the index. The upgrade is going to chuck it away and rebuild a completely new one anyway)

Ok.. I read further in the upgrade instructions and I saw what you said about copying over the home files.  I also saw some mention of copying over any other changed files, but then it's difficult to figure out which files have actually been changed.  I'm tempted to just do an in-place upgrade on the same box with a prior snapshot so that I can just update the files that the JIRA installer notices to have been changed and be done with it - the whole migrate to another box seems tedious.

I don't understand why you are adding huge amounts of complexity to this. Copy the JIRA installation and the home directory. Download the more recent version. Run it and point it at the old version. It will upgrade it. If it's a standard install, you don't care about the modifications to files. If it's a non-standard install, there's a very high chance that you don't care as well. Please, just follow the standard upgrade documentation. As an admin, the 47Mb lines of code don't matter to you because the upgrade process is built to deal with it.

OK, so that's the weird part - the upgrade documentation says to copy everything *after* you run the installer, so that's why I'm confused. Take a look: So step 3.1 is a clean install. After doing the clean install, 3.2 says to copy the home folder over, and then 3.4 says to copy your existing JIRA configurations over to the new install. I don't know if any configuration files have been changed - I didn't install JIRA to begin with. I guess I'll use winmerge to compare the files listed in that section on the current and new installs and hope I catch everything. Seems like some of those files are modified by config.bat. I read some more and have a better understanding on how to handle the DB part so I get that part now. I'll create an empty db and import the XML backup data there and test it to make sure everything looks like it should. When I'm ready to do the final import, do I wipe out the new production db and reimport from a current XML backup, or do I just reimport the latest XML backup? Sorry if these are total newbie questions, but this is my first time doing a JIRA upgrade as the original install predates all of the admins at the company. We're just trying to be thorough. Obviously once I actually do it I'll probably realize it was a very simple process... it's just a bit foreign and I like to wrap my head around this so I understand all the caveats. Thanks!

Sorry, I just saw on the db portion to use the native db backup tools to make a copy and then point the new install at the copy for testing and then final migration. The instructions say to install JIRA first and then connect to the db copy afterwards as it wants you to migrate any customizations first. Should I just let the installer use the built-in db initially and then point it to the db copy, or just point it outright during the install? I didn't know if order really mattered.

If you point the installer at the existing database, it willl attempt the upgrade at that point, so it will be too late to do copies etc. Working with the internal database means you'll have an empty JIRA set up and then discarded later, so it's safer and quicker, just leaves a couple of small redundent files lying around.

Cool - thanks so much for all your help. I'm being pretty slow and deliberate with this process. We're also probably going to be moving from Windows to a linux box in the near future so I'm hoping understanding all the inner workings of what's going on will help with that migration as well. Thanks!

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,338 views 14 20
Join discussion

Atlassian User Groups

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!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot