My Jira server is reporting an inconsistent build number?

[admin admin]

I powered down my Jira server for routine maintenance and when I started it up again it threw this error{

Database: Failed to start JIRA due to a build number inconsistency.

The version of the data present in your database is higher than the version of JIRA you are trying to start.

• Database build number: 800009
• JIRA app build number: 712004

The best solution is to upgrade JIRA to a version that is equal or higher than the version of your data.
You could also try to downgrade your current database build version to match the version of JIRA you are trying to start.
Review our documentation and try what works for you.

}

I do not understand how this happened, but I would like to resolve it ASAP.

[admin admin · Accepted solution]

I resolved this issue by modifying the ${JIRA-INSTALL}/bin/setenv.sh file to add the following line to the start of the file;

JVM_SUPPORT_RECOMMENDED_ARGS="-Djira.downgrade.allowed=true"

With this, my server was capable of downgrading the database to jira-7.12.3 (in line with build 712004) by running the ${JIRA-7.12.3-INSTALL}/bin/start-jira.sh script.

[admin admin · Accepted solution]

Reverting to a previous version was possible by adding
JVM_SUPPORT_RECOMMENDED_ARGS="-Djira.downgrade.allowed=true"
To the top of the ${JIRA_INSTALL_DIR}/bin/setenv.sh file as below;

echo JVM_SUPPORT_RECOMMENDED_ARGS="-Djira.downgrade.allowed=true" | cat - /opt/atlassian/jira/bin/setenv.sh > temp && mv temp /opt/atlassian/jira/bin/setenv.sh

Note that support also mentioned that this capability (presently) only exists for the Jira server.

By comparison, a Confluence server can be redelivered with a database backup;

https://confluence.atlassian.com/confkb/how-to-roll-back-to-a-previous-version-of-confluence-316113136.html
The same cannot be said for Bitbucket, but a feature request does exist;

https://jira.atlassian.com/browse/BSERV-10727

And neither exist for Bamboo as yet.

[bryhoyt]

We've had this happen to us too. My question is, how can it possibly happen that the database build number is *higher* than the Jira app build number, when we haven't touched the Jira installation, and certainly haven't attempted to downgrade it?

Does Jira automatically downgrade itself?

[Klaus Foerschl]

We experienced the same thing now twice on different systems.
One of them 100% sure not touched for a long time and not even having an internet connection which could explain an automated update or similar.
The operating system, all the packages installed and Jira itself are completely unchanged.
Nevertheless, after a maintenance downtime we got this messages.

Can someone from Atlassian please explain, how this comes!?

[JP _AC Bielefeld Leader_]

Well,

it seems that someone might have upgraded a Jira system hooked up to the same database. Maybe a development/testing/staging server was upgraded for some Jira 8 tests after using a backup/image of the production server & someone forgot to configure the JDBC connection to the develop/test database.

Best advice if you cannot upgrade your production server to Jira 8: Use a backup from the database....

Best regards

JP

[admin admin]

Hi Jan-Peter Rusch,

Thanks for your suggestion, but I found an even more useful solution as I mentioned above;
echo JVM_SUPPORT_RECOMMENDED_ARGS="-Djira.downgrade.allowed=true" | cat - /opt/atlassian/jira/bin/setenv.sh > temp && mv temp /opt/atlassian/jira/bin/setenv.sh

By adding this argument to the setenv.sh file, it allows the Jira server to disregard to specified version in the database, and operate on it regardless.

There may be some run-time constraints on this, such as incompatibility with field-names and such in the database itself but, noting I have not done extensive testing to validate, I have not recognized any as yet, with the sub-version modification I implemented this with.

[brbojorque]

@admin admin , you can actually downgrade Jira to previous version. Please run the installer of the previous version and this time do the backup.

To see the complete list of the build number refer to this link.

https://confluence.atlassian.com/jirakb/jira-build-and-version-numbers-reference-347341143.html

[admin admin]

A backup is not going to work, as this change has been live in our environment for a number of days now.
There must be a key in the database that identifies the version, perhaps this could be altered to be compliant?

[JP _AC Bielefeld Leader_]

Hi Shane,

I would opt for an update of your Jira instance to 8.0.0, if you can't grap a recent backup. To be honest, this is a critical situation: Did you contact Atlassian support? Setting the key in the database to a prior version will not solve your problem. The server might come up (I doubt it, so), because you skip a vital check to ensure that the Jira version has a valid database scheme. I'm still wondering that Jira was still running with an inconsistent database backend. One more hint: Find the Jira server which updated your database & make sure that every server uses his own database.

Best of luck,

JP