使用低版本的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 disabled
2015-02-02 12:31:36 27876 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-02-02 12:31:36 27876 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-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.0M
2015-02-02 12:31:36 27876 [Note] InnoDB: Completed initialization of buffer pool
2015-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 pages
2015-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 36755345241838
InnoDB: is in the future! Current system log sequence number 13637542595176.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2015-02-02 12:31:37 2aeb2d96a590 InnoDB: Error: page 1 log sequence number 35468208055287
InnoDB: is in the future! Current system log sequence number 13637542595176.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: 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 server
Connected successfully
Can'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應用日志時存在問題，這一點需注意。
