Upgrade failed, application will not start: com.atlassian.config.ConfigurationException: Cannot update schema
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Problem
When attempting to upgrade from Confluence 5.10.x to 6.1.x or above, the upgrade fails and The following appears in the atlassian-confluence.log:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
ERROR [localhost-startStop-1] [atlassian.confluence.plugin.PluginFrameworkContextListener] launchUpgrades Upgrade failed, application will not start: com.atlassian.config.ConfigurationException: Cannot update schema
com.atlassian.confluence.upgrade.UpgradeException: com.atlassian.config.ConfigurationException: Cannot update schema
at com.atlassian.confluence.upgrade.AbstractUpgradeManager.upgrade(AbstractUpgradeManager.java:135)
at com.atlassian.confluence.plugin.PluginFrameworkContextListener.launchUpgrades(PluginFrameworkContextListener.java:119)
at com.atlassian.confluence.plugin.PluginFrameworkContextListener.contextInitialized(PluginFrameworkContextListener.java:78)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4853)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5314)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1408)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1398)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.atlassian.config.ConfigurationException: Cannot update schema
at bucket.core.persistence.hibernate.schema.SchemaHelper.validateSchemaUpdateIfNeeded(SchemaHelper.java:174)
at com.atlassian.confluence.upgrade.AbstractUpgradeManager.upgrade(AbstractUpgradeManager.java:120)
... 11 more
Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: Attempt to resolve foreign key metadata from JDBC metadata failed to find column mappings for foreign key named [FK9DC3E34D34A4917E]
at org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl$ForeignKeyBuilderImpl.build(InformationExtractorJdbcDatabaseMetaDataImpl.java:885)
at org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl$ForeignKeyBuilderImpl.build(InformationExtractorJdbcDatabaseMetaDataImpl.java:866)
at org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl.getForeignKeys(InformationExtractorJdbcDatabaseMetaDataImpl.java:849)
at org.hibernate.tool.schema.extract.internal.TableInformationImpl.foreignKeys(TableInformationImpl.java:97)
at org.hibernate.tool.schema.extract.internal.TableInformationImpl.getForeignKey(TableInformationImpl.java:108)
at org.hibernate.tool.schema.internal.AbstractSchemaMigrator.findMatchingForeignKey(AbstractSchemaMigrator.java:446)
at org.hibernate.tool.schema.internal.AbstractSchemaMigrator.applyForeignKeys(AbstractSchemaMigrator.java:419)
at org.hibernate.tool.schema.internal.AbstractSchemaMigrator.performMigration(AbstractSchemaMigrator.java:245)
at org.hibernate.tool.schema.internal.AbstractSchemaMigrator.doMigration(AbstractSchemaMigrator.java:110)
at org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:87)
at org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:58)
at bucket.core.persistence.hibernate.schema.SchemaHelper.validateSchemaUpdateIfNeeded(SchemaHelper.java:171)Diagnosis
Environment
Starting on Confluecne 5.10.x or prior
Upgrading to Confluence 6.1.x or newer
Diagnostic Steps
Confirm the Attachment Storage Configuration and not the database.
You can confirm this by running these commands, if they return any results, you have encountered this issue:
1SELECT Count(*) FROM attachments;1SELECT max(lastmoddate) FROM ATTACHMENTS;However, even with zero results, the foreign key should not exist, post-attachment migration.
Cause
This is a failure updating the DB schema during a Confluence upgrade. The error thrown is caused by:
1
Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: Attempt to resolve foreign key metadata from JDBC metadata failed to find column mappings for foreign key named [FK9DC3E34D34A4917E]
This error relates to a hibernate issue: (HHH-10802) Attempt to resolve foreign key metadata from JDBC metadata failed to find column mappings for foreign key - Hibernate JIRA
The upgrade fails due to the foreign key, "fkf0e7436e34a4917e" from content_label table referenced by the attachment_backup table:
1
"fkf0e7436e34a4917e" FOREIGN KEY (attachmentid) REFERENCES attachments_backup(attachmentid)
This appears to be caused by a residual foreign key constraint left over from a prior attachment migration from the DB to the file system. This constraint should have been dropped when the migration of attachments from the database to the filesystem was complete.
Solution
Resolution
You must backup up your database before performing the following task.
Steps to resolve:
Roll back the database to 5.10.8 (or restore the version you were previously running)
Run the following commands to remove the constraint and drop the attachments table (if it exists):
1 2ALTER TABLE attachments DROP CONSTRAINT FKF0E7436E34A4917E;1DROP TABLE ATTACHMENTS;Take another database backup as a precaution
Perform the upgrade to Confluence 6.1.x or newer
As the attachments are now stored in the file system since 5.4+ (by default), dropping the attachments table should not have any negative effects. Post-attachment migration, the info connecting attachment details in the database to files on the filesystem is now stored in the attachmentdata table.
Was this helpful?