Upgrading to the Latest Jira with the Latest Version of MariaDB Server

spacer

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 blog post about it.

Jira on top of MariaDB Server is NOT a supported combination, yet. Jira supports MySQL, but officially not yet MariaDB. 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 here and the wider request for supporting MariaDB Server in Atlassian products in general is found here. 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 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 location directive in Nginx configuration, check for a maintenance file and if found show it for all URLs.

...
location / {
if (-f $document_root/maintenance.html) {
return 503;
}
...
error_page 503 @maintenance;

location @maintenance {
rewrite ^(.*)$ /maintenance.html break;
}

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.

Database backup with the dump utility:

$ mysqldump -u username -p databasename > jiradb20180907.sql
$ tar -zcvf jiradb20180907.tar.gz jiradb20180907.sql

Backup attachments and avatars:

$ tar -zcvf attachments20180908.tar.gz /data/jira/data/attachments/
$ tar -zcvf avatars20180908.tar.gz /data/jira/data/avatars/

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

OS upgrade

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.

Nginx gets upgraded during OS upgrade. Verify by running the command: nginx -v

MariaDB Server upgrade

In our case we had MariaDB Server 10.1 installed. These were the steps to get it to latest stable GA version of MariaDB Server:

  • Stop MariaDB Server 10.1: sudo service mysql stop
  • Uninstall 10.1: sudo apt remove mariadb-server
  • Add a MariaDB Server 10.2 repository. I’ll use the mariadb.com repository setup script:
    curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash -s — –mariadb-server-version=mariadb-10.2
    For more information on the repository script please refer to the documentation.
  • Install 10.2: sudo apt install mariadb-server
  • Verify that MariaDB Server 10.2 is running and works
  • Stop MariaDB: sudo service mysql stop
  • Uninstall 10.2: sudo apt remove mariadb-server
  • Add a MariaDB Server 10.2 repository. I’ll again use the mariadb.com repository setup script:
    curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash -s — –mariadb-server-version=mariadb-10.3
  • Install 10.3: sudo apt install mariadb-server
  • Verify that MariaDB 10.3 is running and works. Check that datadir 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 upgrading Jira itself let’s update the JDBC driver first to not have to restart Jira several times. Updating MariaDB Connector/J is straight forward. 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:

$ wget https://downloads.mariadb.com/Connectors/java/connector-java-2.3.0/mariadb-java-client-2.3.0.jar
$ mv /opt/atlassian/jira/lib/mariadb-java-client-2.1.2.jar ~
$ mv mariadb-java-client-2.3.0.jar /opt/atlassian/jira/lib/

Jira upgrade

Finally upgrade Jira with the Jira installer:

  • The Jira installer is available here: https://www.atlassian.com/software/jira/download
  • Backup jira configuration: sudo tar -zcvf conf20180909.tar.gz /opt/atlassian/jira/conf
  • Stop Jira: sudo service jira stop
  • Start upgrade: sudo ./atlassian-jira-software-7.12.1-x64.bin
  • Follow installer instructions
  • 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 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 learnt 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 blog 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.