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.

[Steve Thornhill · Accepted solution]

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.

[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
@@ -5,12 +5,12 @@
<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

[Artem Baguinski]

And now having studied the generated dbconfig.xml file more carefully I've discovered another difference: a special character in the password needed to be replaced with an XML entity. 

That was probably the real reason and not the other differences.

[Artem Baguinski]

And just for the sake of those finding this later: we were able to confirm that the crucial difference was the XML-escaping of the database password in dbconfig.xml, setting URL format and the driver class name back to the original values didn't cause Jira to complain again.