value is too big for column error when restoring with the backup client
プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。
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.
*Fisheye および Crucible は除く
問題
While restoring content from an old backup file from a MySQL database into a newly created MySQL database 2023-10-24_01-30-41_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 file診断
環境
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.14at the time the backup.
Diagnostic Steps
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:
<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:
<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>
原因
A bug in the database driver causes the size of the columns to change, thus the migration fails. This bug is the one that you hit: Unable to locate Jira server for this macro. It may be due to Application Link configuration.
ソリューション
- 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: