Problems with using a lower version of Xtrabackup to restore a full backup file created by a higher version of Xtrabackup

Recently, you will restore data from multiple MySQL servers using xtrabackup backup to another MySQL server and launch multiple instances using different ports as the review environment. The utility performs an automatic restore process in which several DB instances fail to start. Check the error log in the data directory and find the following startup error:

2015-02-02 12:31:36 27876 [note] Plugin ' federated ' is disabled.2015-02-02 12:31:36 27876 [note] innodb:the InnoDB memory Heap is disabled2015-02-02 12:31:36 27876 [Note] innodb:mutexes and rw_locks use GCC atomic builtins2015-02-02 12:31:36 27876 [note] innodb:compressed tables use zlib 1.2.32015-02-02 12:31:36 27876 [note] innodb:using CPU CRC32 Instructions 2015-02-02 12:31:36 27876 [note] innodb:initializing buffer pool, size = 500.0m2015-02-02 12:31:36 27876 [note] Innodb:c ompleted initialization of buffer pool2015-02-02 12:31:36 27876 [Note] innodb:highest supported file format is Barracuda.  2015-02-02 12:31:36 27876 [Note] innodb:the log sequence numbers 13637542590703 and 13637542590703 in Ibdata files does not  Match the log sequence number 13637542595176 in the ib_logfiles!2015-02-02 12:31:36 27876 [Note] innodb:database is not Shutdown normally!2015-02-02 12:31:36 27876 [note] innodb:starting crash recovery.2015-02-02 12:31:36 27876 [note] InnoD B:reading tablespace inFormation from the. ibd files ... 2015-02-02 12:31:37 27876 [note] innodb:restoring possible half-written data pages2015-02-02 12:31:37 27876 [note] InnoDB : From the Doublewrite buffer ... 2015-02-02 12:31:37 2aeb2d96a590 InnoDB:Error:page 7 log sequence number 36755345241838innodb:is in the future! Current system log sequence number 13637542595176.innodb:your database may corrupt or we have copied the Innodbin Nodb:tablespace but not the InnoDB log files. Seeinnodb:http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlinnodb:for more information.2015-02-02 12:31:37 2aeb2d96a590 InnoDB:Error:page 1 log sequence number 35468208055287innodb:is in the FUT ure! Current system log sequence number 13637542595176.innodb:your database may corrupt or we have copied the Innodbin Nodb:tablespace but not the InnoDB log files. Seeinnodb:http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlinnodb:for more information ....

It is said that the log sequence number in the Ibdata file is inconsistent with the log sequence number in the Ib_logfiles file, initiating the crash recovery process, reading tablespace information from the. ibd file, and recovering the data page from the double write buffer. However, the log sequence number in the Discovery page is ahead of the current system log sequence number. Indicates that the database may be damaged. Or, only table space is not prepared for log files when you back up. Therefore, it can be inferred that the error may occur in two parts: the backup file itself is corrupted, the second backup file itself is not a problem, there is a problem when the log is applied.

Verify from the simple case first
Manual Pull the previous day's xtrabackup full file step-by-step restore process during the Application log phase. The following error was found:

...... 150202 12:36:35  innobackupex:connecting to MySQL server with DSN ' dbi:mysql:;mysql_read_default_file=/etc/my.cnf; Mysql_read_default_group=xtrabackup ' as ' usvr_serveradmin '  (using Password:yes). 150202 12:36:35  innobackupex:connected to MySQL serverconnected Successfullycan ' t call method ' disconnect ' on a undefined value at/usr/ Bin/innobackupex line 1482 .....

Normally when the output of complete ok! So I decided it was a problem here. All machines are restored using the same restore program, why only some of these problems occur? After viewing, these machines are installed with the MySQL version for 5.6.21,xtrabackup version 2.2.24. The MySQL server instance that will eventually be restored to itself is 5.6.12, and the Xtrabackup version is 2.1.3.

After replacing 2.1.3 with xtrabackup2.2.24, the log is re-applied to the full file and the discovery can be executed successfully. So the final question is fixed here. That is, using a fully-prepared file with a higher version of Xtrabackup backup will cause problems when using the lower version of the Xtrabackup application log. (with the MySQL server itself version of the wood has a certain connection)

But then again, the rest of the machine also has a few MySQL5.6.21, the Xtrabackup version is 2.2.24. Why is the restore successful?? Observe the databases of these machines and discover that the databases are empty, so there is no case for fully-prepared application logs. Therefore, a full-backup restore will succeed.

Overall: Use a high version of the Xtrabackup to prepare the issue when using the low version of the Xtrabackup application log, it is important to note.

Problems with using a lower version of Xtrabackup to restore a full backup file created by a higher version of Xtrabackup