Unsupported model and version of the database in use according to health check

Dmitri October 18, 2020

Hello,
we've been using Jira v4 for a long time on our Windows Server. Recently we had to re-install it and did it in a VM using Windows 10 64bit as OS.

We created a trial license and have been installing major versions one by one, i.e.
v5 -> data import from v4, adjusting to the changes, if needed, backup
v6 -> data import from v5, adjusting to the changes, if needed, backup
...
...
to get to the current version 8.13.0. All that worked fine, so that we purchased a new license and wanted to switch from the embedded database to one of the supported databases.

According to Jira documentation PostgreSQL is well tested and a driver for it included, so we decided to give PostgreSQL a try. The docs say that PostgreSQL 11 is supported, so we installed version 11.9 and skipped version 12 or the current version 13. We are new to PostgreSQL, but had a basic idea of how to deal with it due to usage of MySQL for some other projects. Not everything was like in the docs, but I think we got it, because a lot of tables have been created in the database, all our imported issues seem to be fine etc.

Actually everything looks fine in general except the health check. While all sections a marked with a check, the section about supported database says "The model and version of your database are not supported" or something like that, although the section about the embedded database says, that we aren't using the embedded one. Going by that info our instance shouldn't be working, but it does. I would expect "PostgreSQL 11.9" or something like that in the section about the database in use.

Now i'm not sure if it's just a bug of the health check or if something is wrong with our installation, despite looking fine at the first moment.

Any ideas / suggestions?

1 answer

1 accepted

0 votes
Answer accepted
Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 20, 2020

Hi Dmitri,

I understand that you have recently completed a series of upgrades to Jira, but that you still seem to be getting a health check warning about an unsupported database.  I would want to start by checking the $JIRAHOME/dbconfig.xml file to see what exists there. 

This file controls what database Jira connects to when it starts up.  If this is configured properly for Postgres, then we should be able to tell by the parameters and the URL in that file. 

If that looks fine, then I would recommend restarting Jira once more.  This is because if changes have been made to that file, Jira only will pick them up after that file has been saved and Jira restarted, but also because starting Jira up will force it to log some more details within $JIRAHOME/log/atlassian-jira.log file.  This startup log should confirm the database Jira is using, but could also give us more details about what Jira is seeing when it starts up, say if there is some problem with the database in some way.

I have not found any other reports yet of the health check being incorrectly flagged for Postgresql 11 versions in Jira 8.13, but I am interested to try to learn more here in case there is a problem. 

Let me know the results.

Andy

Dmitri October 21, 2020

Hi Andy,

thank you for your response.

Here is the content of the dbconfig.xml:

<?xml version="1.0" encoding="UTF-8"?>

<jira-database-config>
<name>defaultDS</name>
<delegator-name>default</delegator-name>
<database-type>postgres72</database-type>
<schema-name>public</schema-name>
<jdbc-datasource>
<url>jdbc:postgresql://localhost:5432/jiradb</url>
<driver-class>org.postgresql.Driver</driver-class>
<username>xxxxxxxxxxxxx</username>
<password>xxxxxxxxxxxxx</password>
<pool-min-size>20</pool-min-size>
<pool-max-size>20</pool-max-size>
<pool-max-wait>30000</pool-max-wait>
<validation-query>select 1</validation-query>
<min-evictable-idle-time-millis>4000</min-evictable-idle-time-millis>
<time-between-eviction-runs-millis>5000</time-between-eviction-runs-millis>
<pool-max-idle>20</pool-max-idle>
<pool-remove-abandoned>true</pool-remove-abandoned>
<pool-remove-abandoned-timeout>300</pool-remove-abandoned-timeout>
<pool-test-on-borrow>false</pool-test-on-borrow>
<pool-test-while-idle>true</pool-test-while-idle>
</jdbc-datasource>
</jira-database-config>

I had restarted Jira a few times, when I switched the databases plus a restart happens everytime I start up the VM my Jira instance is installed on, so this is not the reason, I think.

What part of the atlassian-jira.log file should I share to provide you more info?

Best regards,

Dmitri

Dmitri October 21, 2020

Hi Andy,

I took a look at the log and think that these parts are relevant:

2020-10-21 10:21:34,915+0200 JIRA-Bootstrap INFO [c.a.jira.startup.JiraStartupLogger] Running Jira startup checks.
2020-10-21 10:21:34,915+0200 JIRA-Bootstrap INFO [c.a.jira.startup.JiraStartupLogger] Jira pre-database startup checks completed successfully.
2020-10-21 10:21:35,512+0200 JIRA-Bootstrap INFO [o.o.c.entity.jdbc.DatabaseUtil] Database Product Name is PostgreSQL
2020-10-21 10:21:35,512+0200 JIRA-Bootstrap INFO [o.o.c.entity.jdbc.DatabaseUtil] Database Product Version is 11.9
2020-10-21 10:21:35,512+0200 JIRA-Bootstrap INFO [o.o.c.entity.jdbc.DatabaseUtil] Database Driver Name is PostgreSQL JDBC Driver
2020-10-21 10:21:35,512+0200 JIRA-Bootstrap INFO [o.o.c.entity.jdbc.DatabaseUtil] Database Driver Version is 42.2.6

Following by several lines like the one below for different entities:

2020-10-21 10:21:39,088+0200 JIRA-Bootstrap INFO [o.o.c.entity.jdbc.DatabaseUtil] Created function based indices for entity "FieldConfigScheme"
[...]

Once this is done, there are some more lines related to the database:

2020-10-21 10:21:42,324+0200 JIRA-Bootstrap INFO [c.a.j.config.database.DatabaseConfigurationManagerImpl] The database is configured. Now running Database Checklist Launcher
2020-10-21 10:21:42,339+0200 JIRA-Bootstrap INFO [c.a.jira.startup.DatabaseChecklistLauncher] Jira database startup checks completed successfully.
2020-10-21 10:21:42,339+0200 JIRA-Bootstrap INFO [c.a.j.config.database.DatabaseConfigurationManagerImpl] The database is configured. Now running Post database-configuration launchers
2020-10-21 10:21:44,638+0200 JIRA-Bootstrap INFO [c.a.j.config.database.SystemDatabaseConfigurationLoader] Reading database configuration from C:\Program Files\Atlassian\Application Data\Jira\dbconfig.xml
2020-10-21 10:21:44,638+0200 JIRA-Bootstrap INFO [c.a.j.config.database.DatabaseConfigHandler] Trying to get encrypted password from xml and decrypt it
2020-10-21 10:21:44,638+0200 JIRA-Bootstrap INFO [c.a.j.config.database.DatabaseConfigHandler] Database password decryption not performed.
2020-10-21 10:21:46,853+0200 JIRA-Bootstrap INFO [c.a.jira.i18n.CachingI18nFactory] [i18n-caching-factory] Created
2020-10-21 10:21:47,572+0200 JIRA-Bootstrap INFO [c.a.j.c.embedded.ofbiz.OfBizUserDao] Using full user cache
2020-10-21 10:21:47,744+0200 JIRA-Bootstrap INFO [c.a.j.c.cache.pauser.NonClusteredReplicationPauserManager] Non-clustered mode: ReplicationPauserManager implemented by NonClusteredReplicationPauserManager
2020-10-21 10:21:48,135+0200 JIRA-Bootstrap INFO [c.a.jira.versioning.TransactionSupportHelper] [VERSIONING] creating pool of size: 50 for running required-new-transaction to be used by versioning.
2020-10-21 10:21:49,946+0200 JIRA-Bootstrap WARN [c.a.j.cache.request.RequestCacheRecorderImpl] Invalid use of RequestCache by thread: JIRA.Incorrect usage of JIRA API. You can only create/use: RequestCacheImpl inside a context (request or Jira-Thread-Local). Check: JiraThreadLocalUtil for details. This message will be logged once per thread.
2020-10-21 10:21:50,400+0200 JIRA-Bootstrap INFO [c.a.jira.upgrade.PluginUpgradeListener] [plugin-upgrade-listener] Created
2020-10-21 10:21:50,400+0200 JIRA-Bootstrap INFO [c.a.jira.plugin.JiraCacheResetter] [jira-cache-reseter] Created and registered for events
2020-10-21 10:21:50,400+0200 JIRA-Bootstrap INFO [c.a.jira.plugin.PluginTransactionListener] [plugin-transaction] Created, registered for events and schedulled stats job
2020-10-21 10:21:50,447+0200 JIRA-Bootstrap INFO [c.a.jira.i18n.CachingI18nFactory] [i18n-caching-factory] Registering for events
2020-10-21 10:21:50,479+0200 JIRA-Bootstrap INFO [c.a.jira.plugin.JiraCacheResetter] [jira-cache-reseter] Initialized.
2020-10-21 10:21:50,479+0200 JIRA-Bootstrap INFO [c.a.jira.plugin.PluginTransactionListener] [plugin-transaction] Initialized.
2020-10-21 10:21:50,589+0200 JIRA-Bootstrap INFO [c.a.jira.startup.DatabaseLauncher] Database transactions enabled: true
2020-10-21 10:21:50,589+0200 JIRA-Bootstrap INFO [c.a.jira.startup.DatabaseLauncher] Using JIRA's default for database transaction isolation level: 2
2020-10-21 10:21:50,619+0200 JIRA-Bootstrap INFO [c.a.jira.startup.JiraStartupLogger]

Database configuration OK

___ Database Configuration ________________

Loading entityengine.xml from : file:/C:/Program%20Files/Atlassian/Jira/atlassian-jira/WEB-INF/classes/entityengine.xml
Entity model field type name : postgres72
Entity model schema name : public
Database Version : PostgreSQL - 11.9
Database Driver : PostgreSQL JDBC Driver - 42.2.6
Database URL : jdbc:postgresql://localhost:5432/jiradb
Database JDBC config : postgres72 jdbc:postgresql://localhost:5432/jiradb

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 23, 2020

Hi Dmitri,

I tried to recreate this problem in my own environment.  I used a postgresql 11.9 database, with the latest Jira 8.13.0 version on a Windows 10 platform.  However in my own install, I was not able to recreate this problem.  The database healthcheck does not appear to throw any warning for me.  Your dbconfig.xml also looks to be correct to me, and nothing in that log appears to be incorrect to me.

The only thing I can think of here that would cause this error in your environment is that older versions of Jira would not support this database version.  For example, the Jira 7 versions won't have support for Postgres 11.  If you were trying to use postgres 11 for a Jira 7.x version, I would expect that this healthcheck warning would appear.   But I do not expect that this warning would appear in Jira 8.13.  

When doing your upgrades, you should have used supported database depending on what version you were upgrading to. Each minor version of Jira could have different supported database model/versions.  I'm not sure if you did that or not here with the information I have right now. If you just tried to use the postgresql 11 version for all the upgrades, then I'm sure some of the older versions would have thrown this kind of healthcheck, however Atlassian did not start bundling these healthchecks until Jira 7 versions.  But it is not clear to me as to why this healthcheck would still appear in 8.13.  It is possible that there are some upgrade tasks that could not be completed during these upgrades due to the differences in database architecture between versions of Postgresql.

Ultimately, I do not believe that this warning is a problem here.  I would like to better understand what steps I can take to reproduce this problem, but I believe you can safely dismiss this warning based on the information we have so far.  It is possible that one of these upgrades has a failed upgrade task, but if you are not seeing any problems with your data, or such warning about these upgrade tasks in the logs of Jira, then I don't think there is any need for concern here.

Andy

Dmitri October 23, 2020

Hi Andy,

thank you for your detailed response.

For all the upgrades from the older Jira versions the embedded database has been used. I only installed PostgreSQL for the first time with Jira 8.13, so that's probably not the reason.

Actually there isn't even a warning as such. Just the result of the health check looks "irritating", because it says that the embedded database is not being used, while it also says that the model and version of my database are not supported.

The attached screenshot is in german, but shows what I mean, I think:
Jira_health_check.png

I didn't notice any errors so far, just wasn't sure if I could ignore this or if something might still be wrong.

Best regards,

Dmitri

Daniel Ebers
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 26, 2020

Hi Dmitri,

is the error message the same when switching to English language?
It would be somewhat funny if only the sentence would have been put into language file with a translation error in it ("werden nicht unterstützt" instead of "wird unterstützt").

Cheers,
Daniel

Like Dmitri likes this
Dmitri October 26, 2020

Hi Daniel,

you are right, it seems to be just a translation error. After switching to English, the sentence is "Your database model and version are supported."

"Problem" solved then, thanks all and sorry, should have tried that myself first...

 

Best regards,

Dmitri

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 26, 2020

Very strange, that screenshot showing the green check indicates everything looks good here.  Granted I do not recommend doing an upgrade to Jira's data using the H2 SQL database, as technically that is not a supported platform for upgrades (only evaluations).  But thanks for the help here @Daniel Ebers !!! My German is pretty poor so I appreciate the additional translation here.

I'll look into creating a translation bug for this one. 

Like Dmitri likes this
Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 26, 2020

Did some digging, found that Atlassian already had an internal ticket about this problem created.  However the public facing ticket on JAC of JRASERVER-69685 was technically created in the wrong project for this support tools plugin.

So I created an appropriate clone of this over in ATST-1026.

Sorry for the mix up of translations here.

Andy

Like Dmitri likes this
Dmitri October 26, 2020

No problem, Andy, thank you for your help too!

Suggest an answer

Log in or Sign up to answer