LP #1669592: MySQL 5.6 fails to start on the incremental backup prepared with 2.4 and non-default innodb_data_file_path

**Reported in Launchpad by Agustín last update 09-03-2017 11:45:56

XtraBackup 2.4 fails to restore backups when a non-default innodb_data_file_path (in this case, two idbata files) is used, but only on 5.6. It works correctly on 5.7, and innobackupex from 2.3 works with 5.6, too.

One full + incremental with xtrabackup 2.3 (using innobackupex) and percona server 5.6 (with innodb_data_file_path = ibdata1:100M;ibdata2:10M:autoextend): OK

One full + incremental with xtrabackup 2.4 and percona server 5.7 (with innodb_data_file_path = ibdata1:100M;ibdata2:10M:autoextend): OK

One full + incremental with xtrabackup 2.4 and percona server 5.6 (with default innodb_data_file_path): OK

One full + incremental with xtrabackup 2.4 and percona server 5.6 (with innodb_data_file_path = ibdata1:100M;ibdata2:10M:autoextend): FAIL

2017-03-01 04:24:06 12014 [ERROR] InnoDB: Cannot create log files because data files are corrupt or not in sync with each other
2017-03-01 04:24:06 12014 [ERROR] Plugin 'InnoDB' init function returned error.
2017-03-01 04:24:06 12014 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2017-03-01 04:24:06 12014 [ERROR] Unknown/unsupported storage engine: InnoDB
2017-03-01 04:24:06 12014 [ERROR] Aborting

Attached go steps to test this, and easily reproduce it. Just start one CentOS 6 vagrant VM and run the provided steps (note that it's all automated, except adding the LSN number to the incremental backup). The innodb_data_file_path is commented, so the defaults are used unless it's edited.

Let me know if you need anything else from my side.

Agustn.