XtraBackup 2.0.2 is not backwards compatible

Bug #1038127 reported by Marc Castrovinci
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Fix Released
High
Sergei Glushchenko
2.0
Fix Released
High
Sergei Glushchenko
2.1
Fix Released
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

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

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.

Revision history for this message
Sergei Glushchenko (sergei.glushchenko) wrote :

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.

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

Sergei -

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

Revision history for this message
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.

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

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
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-338

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.