In the development of MariaDB Server, we use Atlassian's Jira as the issue and project tracking software but also for planning. We have been using Jira since 2012 when we migrated from Launchpad. At that point, we made use of Jira in Atlassian's cloud, but a couple of years later, we decided to install our own instance of Jira and run it on top of MariaDB Server. I've previously written a post about it.

Jira on top of MariaDB Server is NOT a supported combination yet. Jira supports MySQL, but not officially MariaDB yet. We, of course, want as many pieces of software as possible to support MariaDB Server to make it easier for our customers and users. We're not alone with thinking this way. The request for supporting MariaDB Server in Jira is found and the wider request for supporting MariaDB Server in Atlassian products, in general, is found. Add your vote to hopefully get MariaDB Server officially supported soon. But the thing is, even though it's not officially supported, the combination of Jira and MariaDB works great. We upgraded to the latest Jira and the latest version of MariaDB recently.

Before upgrade

After upgrade

OS for Jira

Ubuntu 14.04

Ubuntu 18.04

OS for MariaDB

Ubuntu 14.04

Ubuntu 18.04

Jira version

7.2.1

7.12.1

MariaDB Server version

10.1.35

10.3.9

JDBC driver

MariaDB connector/J 2.1.2

MariaDB connector/J 2.3.0

Web server

Nginx 1.10.1

Nginx 1.14.0

Update Jira Add-Ons

Jira has a lot of plugins and the plugin versions need to be compatible with the version of Jira that is running. There is a tool included in Jira, the Jira Update Check for add-ons, which is found in the URL /plugins/servlet/upm/check. Use that tool to update all the add-ons to versions that will be supported in the Jira version you're going to upgrade to.

Stop Access to Jira

Let's get going with the actual upgrade. Start with making Jira unavailable to users by serving a maintenance page to everyone trying to access Jira. This is easily done with Nginx. In the directive in Nginx configuration, check for a maintenance file, and if found, show it for all URLs.

Backup Database and Directories

Before starting an upgrade, one should, of course, make sure that backups exist. When it comes to Jira, one should have a full backup of the database and of the directories Jira uses for storing attachments and user avatar images. We had a backup tool running on the server producing full backups on a daily basis. In addition, I did a database dump as well using the dump utility.

Copy the backup files to another server in case something goes horribly wrong in the upgrade process.

Our Jira server was running Ubuntu 14.04 and while upgrading software, we also wanted to upgrade the OS. I won't go into the details of the upgrade of Ubuntu, but basically, I ran do-release-upgrade twice to get the server to Ubuntu 18.04. There were a couple of things I had to do. I had to to create the file /etc/update-manager/release-upgrades.d/unauth.cfg and add the following. This was to allow libraries that the release upgrade process couldn't authenticate, which were Galera and MariaDB libraries.

[Distro] AllowUnauthenticated=yes

After the upgrade, remove the unauth.cfg file.

In my case, the upgrade (from 16.04 to 18.04) changed the SSH server configuration and I couldn't SSH to the server anymore. I guess I chose "Yes" somewhere I shouldn't have. Luckily, I had console access and got SSH configured manually.

Verify that MariaDB 10.3 is running and works. Check that in in /etc/mysql/my.cnf is pointing to the directory where you have your database files

JDBC, MariaDB Connector/J Update

Before moving to upgrade Jira itself, let's update the JDBC driver first to not have to restart Jira several times. Updating MariaDB Connector/J is straightforward. Pick up the latest version of Connector/J from downloads.mariadb.com, place it in the lib directory of Jira and remove the old one:

Try to start Jira: sudo service jira start (which will not work since server.xml has been replaced)

As said in the last step, Jira won't start because the installer has replaced the server.xml configuration file. Now you need to change it back to your configuration. An easy way to do it is to make a diff between the server.xml that you had before and this new one. Once the configuration is in place start Jira.

Also remember to remove (or rename) the maintenance.html file used by Nginx, in case you used that way of putting Jira in maintenance mode.

After having Jira up and running again, everything worked well. We learned a couple of days later that there was one thing that didn't work as before. We use Tableau for reporting and we have installed the "All-in-One Tableau Connector for Jira" add-on. It turned out this add-on generated SQL SELECT queries that had the column ROWS in them. ROWS is a reserved word in 10.3, so when asking for a column named that way, one has to backtick the name, i.e. ´ROWS´. Luckily, the company behind this add-on also wanted to make sure the add-on works for us and once we found the reason, they provided us with a new version of the add-on a couple of hours later.

There is one more thing that I had to do. We were using a previous backup version that is not compatible with MariaDB Server 10.3. We recommend that you use MariaDB Backup for your backups. The topic deserves a separate post, and I'll get to that a bit later.

Since our upgrade in September, the latest version of Jira has been up and running all the time on top of the latest version of MariaDB serving users of MariaDB's Jira.