value is too big for column error when restoring with the backup client

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

プラットフォームについて: Server と Data Center のみ - この記事は、サーバーおよびデータセンター プラットフォームのアトラシアン製品にのみ適用されます。

問題

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 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.14 at the time the backup.

診断ステップ

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>

 

原因

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:  AO-320 - Getting issue details... STATUS

ソリューション

最終更新日 2016 年 4 月 6 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.