nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira doesn't pick up a copy of the database

Artem Baguinski

We're preparing for the migration from Jira Server to Cloud.

We need to setup a test Jira instance with a snapshot of production data.

We are rsyncing jira home directory and loading a recent production database dump on the test server.

However, the test Jira doesn't seem to respect the database configuration and enters the initial setup wizard.

What we have checked:

/var/atlassian/application-data/jira/dbconfig.xml on the test server is the same as on the production
jira unix user can access this file
jira is running under this user
configured jira database user can access the database and access the tables

Relevant (?) log porion of the test jira:

2023-12-14 11:26:44,558+0100 JIRA-Bootstrap INFO [c.a.j.config.database.SystemDatabaseConfigurationLoader] Reading database configuration from /var/atlassian/application-data/jira/dbconfig.xml
2023-12-14 11:26:44,570+0100 JIRA-Bootstrap INFO [c.a.j.instrumentation.external.DatabaseExternalGauges] Installing DBCP monitoring instruments: DatabaseExternalGauges.JiraDbcpInstruments[instruments=[DBCP_MAX, DBCP_ACTIVE, DBCP_IDLE],objectName=com.atlassian.jira:name=BasicDataSource]
2023-12-14 11:26:44,598+0100 JIRA-Bootstrap INFO [c.a.jira.startup.JiraStartupLogger] Running Jira startup checks.
2023-12-14 11:26:44,599+0100 JIRA-Bootstrap INFO [c.a.jira.startup.JiraStartupLogger] Jira pre-database startup checks completed successfully.
2023-12-14 11:26:44,641+0100 JIRA-Bootstrap INFO [c.a.j.config.database.DatabaseConfigurationManagerImpl] The database is not yet configured. Enqueuing Database Checklist Launcher on post-database-configured-but-pre-database-activated queue
2023-12-14 11:26:44,641+0100 JIRA-Bootstrap INFO [c.a.j.config.database.DatabaseConfigurationManagerImpl] The database is not yet configured. Enqueuing Post database-configuration launchers on post-database-activated queue
2023-12-14 11:26:44,715+0100 JIRA-Bootstrap INFO [c.a.jira.startup.LauncherContextListener] Startup is complete. Jira is ready to serve.

Accepted answers

Steve Thornhill_57zt4f

Been a while since I last did this, but if you set up the test server as an empty Jira ( go through the db setup etc as if it was a new implementation )and then shut it down, you can restore the database from your backup over the top of that database instance and when Jira starts up it should read the data correctly.

All comments

Steve Thornhill_57zt4f

Artem Baguinski

Thanks for thinking with us.

I forgot to mention that but that's essentially what we did as well: first went through the bootstrap wizard just to make sure everything else works, then stopped jira and THEN loaded the database dump and synced jira home.

May be we should try again just to see what happens if we try to bootstrap over existing database.

I'll report back once we gave it another go :-)

Artem Baguinski

oke, that was a very quick test, we're getting "You have specified a database that is not empty, please specify an empty database. If you want to upgrade an existing installation, please follow these instructions instead." in that case.

Artem Baguinski

I have retraced my steps and found what was goig wrong.

Our initial jira setup automation unconditionally overwrites the dbconfig.xml. I thought nothing of it since the only difference in this file between test and production was the jira user's password.

However if I remove the file and the database and let the bootstrap wizard generate the file from scratch there are more differences:

# diff -u dbconfig.xml /var/atlassian/application-data/jira/dbconfig.xml 
--- dbconfig.xml 2023-12-14 11:37:44.708551977 +0100
+++ /var/atlassian/application-data/jira/dbconfig.xml 2023-12-14 13:30:30.329259004 +0100

<delegator-name>default</delegator-name>
<database-type>mysql8</database-type>
<jdbc-datasource>
- <url>jdbc:mysql://localhost:3306/jira</url>
- <driver-class>com.mysql.jdbc.Driver</driver-class>
+ <url>jdbc:mysql://address=(protocol=tcp)(host=localhost)(port=3306)/jira?sessionVariables=default_storage_engine=InnoDB</url>
+ <driver-class>com.mysql.cj.jdbc.Driver</driver-class>
<username>jira</username>

...

 <validation-query-timeout>3</validation-query-timeout>
+ <connection-properties>nullDatabaseMeansCurrent=true</connection-properties>
</jdbc-datasource>
</jira-database-config>

Apparently the new jdbc driver on the test server uses a different class, URL format and helpfully adds a missing connection property.

After having made sure genertated dbconfig.xml wasn't being overwritten we were able to load the production backup and have Jira start up.

Thanks for pointing us in the right direction, Steve