value is too big for column error when restoring with the backup client
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
While restoring content from an old backup file from a MySQL database into a newly created MySQL database using the Bitbucket Server Backup Client, it fails and the following appears in the <path/to/backup/client>/log/atlassian-sbc-YYYY-MM-DD-HHMM.log:
2015-12-21 16:16:04,883 INFO Restoring ActiveObjects data
2015-12-21 16:16:05,542 INFO Restoring ActiveObjects table definitions
2015-12-21 16:16:06,443 INFO Restoring ActiveObjects table data
2015-12-21 16:16:06,794 ERROR bitbucket-backup.tar could not be restored. Reason: There was an error during import/export with <unknown plugin> (table AO_CFE8FA_BUILD_STATUS):Could not import data in table 'AO_CFE8FA_BUILD_STATUS' column #1, value is too big for column which size limit is 30, value is:
e8b17bbf6bd0fe7a96bb85e0988aafb545d8cde8
com.atlassian.activeobjects.spi.ActiveObjectsImportExportException: There was an error during import/export with <unknown plugin> (table AO_CFE8FA_BUILD_STATUS):Could not import data in table 'AO_CFE8FA_BUILD_STATUS' column #1, value is too big for column which size limit is 30, value is:
e8b17bbf6bd0fe7a96bb85e0988aafb545d8cde8
at com.atlassian.bitbucket.internal.backup.client.ao.DetachedImportExportErrorService.newImportExportException(DetachedImportExportErrorService.groovy:25) ~[bitbucket-restore-client.jar:2.0.1]
at com.atlassian.dbexporter.importer.DataImporter.importTable(DataImporter.java:125) ~[activeobjects-plugin-1.0.1.jar:na]
... 14 more frames available in the log fileEnvironment
The issue occurs if you backed up a Bitbucket server instance that was running with a driver up to version mysql-connector-java-5.1.14 at the time of the backup.
Diagnosis
The problem occurs because the size of the columns defined on the origin backup are incorrect due to the bug described above. To confirm that is the case, would you please be able to:
Extract the original backup file you're trying to restore - it is called something like stash-YYYYMMDD-HHMMSS-ZZZ
Inside it, there will be a file called system.zip
If you unzip it, you should be able to find a file called active-objects-data.xml
The description of this table is incorrect on the backup (source) and we should be able to see the following (incorrect) precision values. They should match the description of the table restored by you - according to that, something likely the description below is the output:
The table should be described as:
mysql> describe AO_CFE8FA_BUILD_STATUS;
+-------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+----------------+
| CSID | varchar(40) | NO | MUL | NULL | |
| DATE_ADDED | datetime | NO | | NULL | |
| DESCRIPTION | varchar(255) | YES | | NULL | |
| ID | int(11) | NO | PRI | NULL | auto_increment |
| KEY | varchar(255) | NO | | NULL | |
| NAME | varchar(255) | YES | | NULL | |
| STATE | varchar(255) | NO | | NULL | |
| URL | varchar(450) | NO | | NULL | |
+-------------+--------------+------+-----+---------+----------------+
8 rows in set (0.00 sec)However, in the file you will find incorrect precision values which will be in turn used by the restore client incorrectly:
active-objects-data.xml
<table name="AO_CFE8FA_BUILD_STATUS">
<column name="CSID" primaryKey="false" autoIncrement="false" sqlType="12" precision="30"/>
<column name="DATE_ADDED" primaryKey="false" autoIncrement="false" sqlType="93" precision="29" scale="6"/>
<column name="DESCRIPTION" primaryKey="false" autoIncrement="false" sqlType="12" precision="191"/>
<column name="ID" primaryKey="true" autoIncrement="true" sqlType="4" precision="11"/>
<column name="KEY" primaryKey="false" autoIncrement="false" sqlType="12" precision="191"/>
<column name="NAME" primaryKey="false" autoIncrement="false" sqlType="12" precision="191"/>
<column name="STATE" primaryKey="false" autoIncrement="false" sqlType="12" precision="191"/>
<column name="URL" primaryKey="false" autoIncrement="false" sqlType="12" precision="337"/>
</table>There, you should be able to confirm which driver was used to perform the "faulty" backup as well:
active-objects-data.xml
<database>
<meta key="database.name" value="MySQL"/>
<meta key="database.version" value="xxxx"/>
<meta key="database.minorVersion" value="x"/>
<meta key="database.majorVersion" value="x"/>
<meta key="driver.name" value="MySQL-AB JDBC Driver"/>
<meta key="driver.version" value="mysql-connector-java-5.1.14 ( Revision: ${bzr.revision-id} )"/>
</database>Cause
A bug in the database driver causes the size of the columns to change, thus the migration fails.
Solution
Change the MySQL driver used by the instance that was backed up by you to the latest version available. You can find the instructions on how to do that on the link below:
Take a new backup of the instance. Instructions below:
After checking that the backup now contains the correct definitions (see expected field sizes on the "Diagnosis" section), restore the backup using the procedure below:
Was this helpful?