Health Check collation correct but fails.

JustinDooley February 21, 2018

I recently upgraded Jira to a the latest version but the database seems to have a few issues. I get an error on my health check that says the following. 
Capture.JPGThe strange part is that from mysql, the function runs correctly. The database is set to utf8 and the tables/columns are set to utf8_bin. I've verified this in the terminal. This does not stop new issues from being created. It just returns an error when quickly creating an issue.  The issue does get created if you refresh or navigate away though. 

Capture2.JPG

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.
February 21, 2018

Hi Justin,

While it can be common to see this health check warning, that specific error you seen when creating an issue is not common.  In turn it could be an indication of other potential problems here.   I think it would be best to try to follow these steps as a means to make sure that your data and your database is using a collation/encoding that Jira is expecting.

 

  1. Select a database type/version from our Supported platforms - Atlassian Documentation
  2. Create a new blank database per Connecting JIRA to a database, (paying close attention to the correct collation for that database type)
  3. Gather an XML backup of your JIRA instance. Even if you can't start JIRA, you can still find a recent one of these backups in the filesystem of the JIRA server. By default this is saved in <jira-home>/export/ folder
  4. Stop JIRA,
  5. Run the JIRA Configuration tool to tell JIRA to use the new blank database, save these changes, (if you can't run this, then you can just directly edit the <jira-home>/dbconfig.xml file to make these changes)
  6. Start JIRA up again (when JIRA starts with an empty database, it automatically launches the setup wizard)
  7. Copy the export XML zip file from <jira-home>/export/ into <jira-home>/import/
  8. Then you can import the backup using the 'Import your data' link in the setup wizard

By following these steps you can then import your previous data into a supported database with the correct database setup.

I have seen these steps are typically the best to follow in order to make sure you can still maintain your data and get everything into an expected format for Jira.   The really important part is to make sure that you follow that database setup guide when creating this database, such as https://confluence.atlassian.com/adminjiraserver077/connecting-jira-applications-to-mysql-945532531.html

Please try these steps first.  I would be interested to know if these steps can help resolve both the health check warning and this error message at the same time.

Cheers,

Andy

JustinDooley February 21, 2018

This seems to have made things a little bit worse. At this point we can't get Jira to start. 

We went in and made the changes to the mysql server for version 5.6. Ensured the proper settings where in place and created a new version we also ran the config tool target the new database. 

The startup log in catalina.out spits out the following (stack traces omitted) 

2018-02-21 14:01:44,688 JIRA-Bootstrap ERROR [c.a.jira.health.HealthChecks] We couldn't start JIRA
2018-02-21 14:01:44,688 JIRA-Bootstrap ERROR [c.a.jira.health.HealthChecks] An error occurred while trying to start JIRA. We can't give you any more detail right now, we suggest checking the logs for more detail and contacting our support team.
See our documentation for more information on contacting our support team and creating a support zip.
2018-02-21 14:01:44,688 JIRA-Bootstrap INFO [c.a.jira.startup.DatabaseLauncher] Database transactions enabled: true
2018-02-21 14:01:44,689 JIRA-Bootstrap INFO [c.a.jira.startup.DatabaseLauncher] Using JIRA's default for database transaction isolation level: 2
2018-02-21 14:01:44,700 JIRA-Bootstrap WARN [c.a.jira.startup.DatabaseLauncher] JRADEV-23357: unable to select from the 'MovedIssueKey' entity.
2018-02-21 14:01:44,703 JIRA-Bootstrap ERROR [c.a.jira.startup.LauncherContextListener] Unable to start JIRA.

After about 10 minutes the server started up but we get a security warning when going to the home page.  (IP address omitted )



21-Feb-2018 14:11:11.409 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-nio-8080]
21-Feb-2018 14:11:11.429 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read
21-Feb-2018 14:11:11.446 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 581552 ms
2018-02-21 14:16:01,279 http-nio-8080-exec-1 ERROR anonymous 856x1x1 - xx.xxx.xxx.xx / [c.atlassian.instrumentation.Instrument] Unable to snapshot thread local operations (implementation of OpTimerFactory is not a ThreadLocalOpTimerFactory): null
2018-02-21 14:16:01,653 http-nio-8080-exec-2 WARN anonymous 856x2x1 - xx.xxx.xxx.xx /secure/errors.jsp [c.a.jira.security.JiraSecurityFilter] Rejecting security-sensitive request that bypassed Johnson filter: /secure/errors.jsp
2018-02-21 14:19:56,997 http-nio-8080-exec-4 WARN anonymous 859x4x1 - xx.xxx.xxx.xx /secure/errors.jsp [c.a.jira.security.JiraSecurityFilter] Rejecting security-sensitive request that bypassed Johnson filter: /secure/errors.jsp
2018-02-21 14:20:04,783 http-nio-8080-exec-6 WARN anonymous 860x6x1 - xx.xxx.xxx.xx /secure/errors.jsp [c.a.jira.security.JiraSecurityFilter] Rejecting security-sensitive request that bypassed Johnson filter: /secure/errors.jsp

 

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 21, 2018

Hi Justin,

Sorry to hear this did not go as expected.   If this is a production instance, you should just be able to stop Jira, run the config tool again and select the previous database, save, and start Jira again.

But regardless, I would like to gather more logs from your instance so that we can help troubleshoot this.  I am afraid our community site isn't great for including log files just yet, so I created a support request where you can do this on https://getsupport.atlassian.com/servicedesk/customer/portal/20/GHS-108849

I will post there shortly and ask for some specific files so we can better understand this problem.

Andy

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 22, 2018

Hi Justin,

Thanks for responding in the support case.  Before I could look at your update, it looks like you already found the solution.  Just in case other users might encounter this same problem I believe the issue was in regards to the dbconfig.xml had a <schema-name>PUBLIC</schema-name> tag in it.   This is appropriate for the H2 SQL database, but not for a MySQL database.   In turn it was forcing jira to try to use a database schema that wasn't really appropriate for that specific database.

Once that was removed, that file saved, and Jira started it appears this problem has been resolved.

Thanks again,

Andy

Suggest an answer

Log in or Sign up to answer