使用低版本的Xtrabackup還原較高版本的Xtrabackup建立的全備份檔案存在的問題，xtrabackup較高

使用低版本的Xtrabackup還原較高版本的Xtrabackup建立的全備份檔案存在的問題，xtrabackup較高
最近要將使用xtrabackup備份的多台MySQL Server的資料還原到另外一台MySQL伺服器上並使用不同的連接埠啟動多個執行個體來作為review環境。公用程式執行自動還原的過程中有幾個資料庫執行個體啟動失敗。檢查資料目錄中的錯誤記錄檔，發現如下啟動錯誤：

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 instructions2015-02-02 12:31:36 27876 [Note] InnoDB: Initializing buffer pool, size = 500.0M2015-02-02 12:31:36 27876 [Note] InnoDB: Completed 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 do not match the log sequence number 13637542595176 in the ib_logfiles!2015-02-02 12:31:36 27876 [Note] InnoDB: Database was not shutdown normally!2015-02-02 12:31:36 27876 [Note] InnoDB: Starting crash recovery.2015-02-02 12:31:36 27876 [Note] InnoDB: 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 be corrupt or you may have copied the InnoDBInnoDB: 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 future! Current system log sequence number 13637542595176.InnoDB: Your database may be corrupt or you may have copied the InnoDBInnoDB: tablespace but not the InnoDB log files. SeeInnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlInnoDB: for more information.……

是說ibdata檔案中的記錄序號與ib_logfiles檔案中的記錄序號不一致，啟動崩潰恢複過程，從.ibd檔案讀資料表空間資訊，從雙寫緩衝恢複資料頁。但發現頁中的記錄序號超前於當前系統記錄序號。提示資料庫可能損毀。或者備份時只備了資料表空間沒備記錄檔。因此，推測錯誤可能發生在兩個環節：一備份檔案本身損壞了；二備份檔案本身沒有問題，在應用日誌的時候出現了問題。

先從簡單的情況驗證
手動拉取前一天的xtrabackup全備檔案一步步執行還原過程，在應用日誌階段。發現如下報錯：

……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 an undefined value at /usr/bin/innobackupex line 1482.……

正常情況下當輸出complete ok！所以斷定是這裡出問題了。所有機器都是使用同樣的還原程式進行還原的，為什麼只有某幾台發生這樣的問題？經查看，這些機器是安裝的MySQL版本為5.6.21，xtrabackup版本為2.2.24。而最終要還原到的MySQL Server執行個體本身是5.6.12的，xtrabackup版本為2.1.3。

使用xtrabackup2.2.24替換2.1.3後重新對全備檔案應用日誌，發現可以成功執行。所以最終問題定位到了這裡。也即，使用高版本的xtrabackup備份的全備檔案，在使用低版本的xtrabackup應用日誌時會出問題。（與MySQL Server本身的版本木有必然聯絡）

但接下來問題又來了，其餘的一些機器中也存在少數幾台MySQL5.6.21的，xtrabackup版本為2.2.24的。為什麼還原成功？？觀察這幾台機器的資料庫，探索資料庫均為空白，這樣也就不存在對全備應用日誌的情況。因而全備還原會成功。

綜上：使用高版本的xtrabackup備的全備在使用低版本的xtrabackup應用日誌時存在問題，這一點需注意。