XtraBackup 2.0.2 is not backwards compatible

Bug #1038127 reported by Marc Castrovinci on 2012-08-17
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup
High
Sergei Glushchenko
2.0
High
Sergei Glushchenko
2.1
High
Sergei Glushchenko

Bug Description

When restoring a backup that was made with version 2.0.1 using the new version 2.0.2, it fails on incrementals.

xtrabackup_55 version 2.0.2 for Percona Server 5.5.16 Linux (x86_64) (revision id: undefined)
incremental backup from 28608289930 is enabled.
xtrabackup: cd to /restore/mysql/base/2012-08-14_06-30-09
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(28608354494)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /restore/mysql/incr/2012-08-14_06-30-09/2012-08-14_07-00-10
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
120817 10:04:56 InnoDB: Using Linux native AIO
120817 10:04:56 InnoDB: Warning: allocated tablespace 1675, old maximum was 9
xtrabackup: Error: xtrabackup_apply_delta(): failed to apply /restore/mysql/incr/2012-08-14_06-30-09/2012-08-14_07-00-10/ibdata1.delta to /restore/mysql/base/2012-08-14_06-30-09/ibdata1.

After downgrading Xtrabackup, it restores fine.

Related branches

lp:~sergei.glushchenko/percona-xtrabackup/xb20-bug1038127
Alexey Kopytov (community): Approve on 2012-09-04
Laurynas Biveinis: Approve on 2012-09-03
lp:~sergei.glushchenko/percona-xtrabackup/xb21-bug1038127
Laurynas Biveinis: Approve on 2012-09-05

Does it happen on all incremental backups taken with 2.0.1 and restored with 2.0.2 or just some particular ones?

Looking at the relevant source code, since there is no "xtrabackup: page size for %s is %lu bytes\n" in the output, it must be either get_meta_path() or xb_read_delta_metadata() failure. Neither of which has changed between 2.0.1 and 2.0.2, this needs further analysis.

Space ids are stored now in .meta files by xb_write_delta_metadata/xb_read_delta_metadata. This could cause the issue. Possible workaround is to prepare backup with 2.0.1 before upgrading to 2.0.2.

Sergei -

So I guess XB should be updated to understand both old and new .meta formats?

Alexey Kopytov (akopytov) wrote :

Yes, space_id should have been made an optional value in xb_read_delta_metadata(). Since we are going to have more optional fields in metadata files, we should rework the way they are parsed.

Also would be a good idea to ensure that xtrabackup_apply_delta() does not do "goto error;" silently without displaying what exactly failed first (there are a few places like this now).

summary: - XtraBackup 2.0.2 is not backwards compatable
+ XtraBackup 2.0.2 is not backwards compatible
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers