Documentation for JIRA 6.4 EAP. Not using this? See below:
(JIRA 6.3.x documentation | JIRA Cloud documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

When upgrading JIRA, one points the new JIRA installation at the old JIRA database. JIRA will automatically make any structural database modifications required to support new JIRA features.

To be safe, JIRA first tries to create an XML backup of your data at the point just before the upgrade. This would allow you to 'roll back' to the old JIRA version, should anything go wrong.

Sometimes the automatic XML backup procedure fails, often resulting from characters in the database which cannot be represented in XML — such as non-displayable control characters that have been 'cut-and-pasted' into a JIRA field.

In these circumstances, you can force the upgrade to proceed by editing your jira-config.properties file (in the JIRA Home Directory) and setting the property jira.autoexport=false
(info) See Making changes to the jira-config.properties file for more information.

After having successfully upgraded JIRA, it is best to remove this property (or disable it with a '#') as it should no longer be required.

If you have any upgrade problems not covered here or in the upgrade documentation, please contact us — we're happy to help.

8 Comments

  1. Anonymous

    So why doesn't the XML backup utility properly escape illegal characters when creating the XML backup and avoid this whole issue?

    Escaping characters is pretty standard behavior of all XML utilities...

  2. Anonymous

    The described solution does not work for me.

    Even creating jira-config.properties in home dir, the log files shown that jira.autoexport is still true.

    I even tried to put a system property -Djira.autoexport=false, but it does'n help

    I try to upgrade 4.2.1 ver to 4.3.4

    1. Hello there,

      The header at the top of this page indicates that this documentation is for the Early Access Program (EAP) of JIRA version 4.4. (While this version of JIRA has not yet been officially released, 'developmental' releases of this version, along with its documentation, are being made publicly available to interested parties keen on trying out the upcoming features in JIRA.)

      To get to the 'Disabling Auto-Export' page in the documentation for the latest official version of JIRA (i.e. version 4.3), then in the header, please click the 'view this page' link in the statement:

      If you are using JIRA 4.3.x either view this page in the JIRA 4.3.x documentation...

      (info) Incidentally, the 'view this page in the JIRA 4.3.x documentation...' link should be available for most pages in the JIRA 4.4 EAP documentation. (The only times it won't be available is if we had to change the documentation page name between versions.)

      Lastly, to help us improve our documentation management processes, could I ask how you found this page? Did you reach it from a Google search result or did you get to it by some other means (and if so, from where)?

      Kind regards,
      Giles.

      1. Anonymous

        The Jira EAP documentation pages show up WAY to frequently as a top result on google.

  3. Anonymous

    I've used the same workaround for a similar problem :

    SQL Exception while executing the following:SELECT ID, NAME, DESCRIPTION, mailfrom, PREFIX, smtp_port, protocol, server_type, SERVERNAME, JNDILOCATION, mailusername, mailpassword, ISTLSREQUIRED, TIMEOUT FROM jira.mailserver ([-4005] (at 60): Unknown column name:PROTOCOL)
        at com.atlassian.core.action.ActionUtils.checkForErrors(ActionUtils.java:46)
        at com.atlassian.jira.bean.export.AutoExportImpl.exportData(AutoExportImpl.java:106)
        at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgradeIfNeeded(UpgradeManagerImpl.java:347)
        at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgradeIfNeededAndAllowed(UpgradeManagerImpl.java:308)
        at com.atlassian.jira.upgrade.UpgradeLauncher.checkIfUpgradeNeeded(UpgradeLauncher.java:100)
        at com.atlassian.jira.upgrade.UpgradeLauncher.start(UpgradeLauncher.java:49)

    This has happen when i started upgrade om my 4.2.1 Jira to 4.3.4

    i found that the mailserver table in new jira is changed (some new colums ae added) - and the column name:PROTOCOL

    exist in new DB, but really is missing in the old one.

    Anyway..i disabled autoexport feature and the upgrade passed. now i have working Jira 4.3.4 , but when i tried to make a backup, the same error appears

    it seems that the upgrade procedure didn't migrated the mailserver table...Does it a bug?

    ...or it may be becouse i've deleted my mailserver definition in Jira4.2.1 before the start of upgrade and the migration was not performed this way...?

  4. Anonymous

    I'm Sorry - the exception is the same, but the stacktrace is different, which may be important for you, thus i paste it here :

    Error exporting: org.ofbiz.core.entity.GenericDataSourceException: SQL Exception while executing the following:SELECT ID, NAME, DESCRIPTION, mailfrom, PREFIX, smtp_port, protocol, server_type, SERVERNAME, JNDILOCATION, mailusername, mailpassword, ISTLSREQUIRED, TIMEOUT FROM jira.mailserver ([-4005] (at 60): Unknown column name:PROTOCOL)
    org.ofbiz.core.entity.GenericDataSourceException: SQL Exception while executing the following:SELECT ID, NAME, DESCRIPTION, mailfrom, PREFIX, smtp_port, protocol, server_type, SERVERNAME, JNDILOCATION, mailusername, mailpassword, ISTLSREQUIRED, TIMEOUT FROM jira.mailserver ([-4005] (at 60): Unknown column name:PROTOCOL)
        at org.ofbiz.core.entity.jdbc.SQLProcessor.prepareStatement(SQLProcessor.java:533)
        at org.ofbiz.core.entity.GenericDAO.selectListIteratorByCondition(GenericDAO.java:1057)
        at org.ofbiz.core.entity.GenericHelperDAO.findListIteratorByCondition(GenericHelperDAO.java:178)
        at org.ofbiz.core.entity.GenericDelegator.findListIteratorByCondition(GenericDelegator.java:1014)
        at org.ofbiz.core.entity.GenericDelegator.findListIteratorByCondition(GenericDelegator.java:987)
        at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.atlassian.multitenant.impl.MultiTenantComponentFactoryImpl$AbstractMultiTenantAwareInvocationHandler.invokeInternal(MultiTenantComponentFactoryImpl.java:181)
        at com.atlassian.multitenant.impl.MultiTenantComponentFactoryImpl$MultiTenantAwareMethodInterceptor.intercept(MultiTenantComponentFactoryImpl.java:230)
        at org.ofbiz.core.entity.GenericDelegator$$EnhancerByCGLIB$$1391d211.findListIteratorByCondition(<generated>)
        at com.atlassian.jira.action.admin.export.DefaultSaxEntitiesExporter.exportEntities(DefaultSaxEntitiesExporter.java:69)
        at com.atlassian.jira.action.admin.DataExport.execute(DataExport.java:97)
        at webwork.interceptor.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:39)

  5. Anonymous

    It seems like the upgrade path from 5.0.5 to 5.1.0 is broken.  I am getting DB errors like above as well. Mine were on different tables.  It looks like they forgot to add the DB update to the Upgrade package (sad).

    I added the fields that were missing from the first error, and it got past it, only to expose the next layer of the onion. 

    When will this be fixed????

     

    Here is what Im seeing:

    DescriptionTimeLevelException
    An error occurred performing JIRA upgrade2012-07-17 14:00:00error
    Error occurred during export before upgrade: Error exporting data: org.ofbiz.core.entity.GenericDataSourceException: SQL Exception while executing the following:SELECT ID, CREATED, TOKEN, TOKEN_SECRET, TOKEN_TYPE, CONSUMER_KEY, USERNAME, TTL, spauth, CALLBACK, spverifier, spversion, SESSION_HANDLE, SESSION_CREATION_TIME, SESSION_LAST_RENEWAL_TIME, SESSION_TIME_TO_LIVE FROM oauthsptoken (Invalid column name 'SESSION_HANDLE'.)
     If necessary, auto-export can be disabled; see http://www.atlassian.com/software/jira/docs/latest/upgrade/autoexport.html
    com.atlassian.core.AtlassianCoreException: Error exporting data: org.ofbiz.core.entity.GenericDataSourceException: SQL Exception while executing the following:SELECT ID, CREATED, TOKEN, TOKEN_SECRET, TOKEN_TYPE, CONSUMER_KEY, USERNAME, TTL, spauth, CALLBACK, spverifier, spversion, SESSION_HANDLE, SESSION_CREATION_TIME, SESSION_LAST_RENEWAL_TIME, SESSION_TIME_TO_LIVE FROM oauthsptoken (Invalid column name 'SESSION_HANDLE'.)
    	at com.atlassian.jira.bean.export.AutoExportImpl.exportData(AutoExportImpl.java:109)
    	at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgradeIfNeeded(UpgradeManagerImpl.java:369)
    	at com.atlassian.jira.upgrade.UpgradeManagerImpl.doUpgradeIfNeededAndAllowed(UpgradeManagerImpl.java:325)
    	at com.atlassian.jira.upgrade.UpgradeLauncher.checkIfUpgradeNeeded(UpgradeLauncher.java:100)
    	at com.atlassian.jira.upgrade.UpgradeLauncher.start(UpgradeLauncher.java:49)
    	at com.atlassian.jira.startup.DefaultJiraLauncher$3.run(DefaultJiraLauncher.java:103)
    	at com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrEnqueue(DatabaseConfigurationManagerImpl.java:284)
    	at com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrWhenDatabaseActivated(DatabaseConfigurationManagerImpl.java:169)
    	at com.atlassian.jira.startup.DefaultJiraLauncher.postDbLaunch(DefaultJiraLauncher.java:94)
    	at com.atlassian.jira.startup.DefaultJiraLauncher.access$100(DefaultJiraLauncher.java:24)
    	at com.atlassian.jira.startup.DefaultJiraLauncher$1.run(DefaultJiraLauncher.java:61)
    	at com.atlassian.jira.util.devspeed.JiraDevSpeedTimer.run(JiraDevSpeedTimer.java:33)
    	at com.atlassian.jira.startup.DefaultJiraLauncher.start(DefaultJiraLauncher.java:56)
    	at com.atlassian.jira.startup.LauncherContextListener$1.create(LauncherContextListener.java:67)
    	at com.atlassian.jira.startup.LauncherContextListener$1.create(LauncherContextListener.java:62)
    	at com.atlassian.multitenant.impl.MultiTenantComponentMapImpl.get(MultiTenantComponentMapImpl.java:121)
    	at com.atlassian.multitenant.impl.MultiTenantComponentMapImpl.onTenantStart(MultiTenantComponentMapImpl.java:165)
    	at com.atlassian.multitenant.impl.DefaultMultiTenantManager$1.consume(DefaultMultiTenantManager.java:134)
    	at com.atlassian.multitenant.impl.DefaultMultiTenantManager$1.consume(DefaultMultiTenantManager.java:131)
    	at com.atlassian.multitenant.impl.DefaultMultiTenantManager.runForEachListener(DefaultMultiTenantManager.java:256)
    	at com.atlassian.multitenant.impl.DefaultMultiTenantManager.startTenant(DefaultMultiTenantManager.java:130)
    	at com.atlassian.multitenant.impl.DefaultMultiTenantManager.startAll(DefaultMultiTenantManager.java:203)
    	at com.atlassian.jira.startup.LauncherContextListener.contextInitialized(LauncherContextListener.java:95)
    	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4205)
    	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4704)
    	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
    	at org.apache.catalina.core.StandardHost.start(StandardHost.java:840)
    	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
    	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
    	at org.apache.catalina.core.StandardService.start(StandardService.java:525)
    	at org.apache.catalina.core.StandardServer.start(StandardServer.java:754)
    	at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    	at java.lang.reflect.Method.invoke(Method.java:597)
    	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
    	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
    
    1. Anonymous

      I had the same error updating from 5.0.1 to 5.1.1, but adding jira.autoexport=false to jira-config.properties as explained above allowed me to complete the upgrade. (I had done a db-level backup already so wasn't terribly concerned skipping the step.)