在沒有準備步驟的情況下從 percona-xtrabackup 還原後，ib_logfile0並且ib_logfile1不存在於還原數據中。因此，在啟動期間會觀察到以下消息：

140223 04:10:24 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
140223 04:46:51 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140223  4:46:51  InnoDB: Initializing buffer pool, size = 18.0G
140223  4:46:54  InnoDB: Completed initialization of buffer pool
140223  4:46:54  InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
140223  4:46:54  InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140223  4:46:54  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
140223  4:46:55  InnoDB: Error: page 7 log sequence number 45 3368182252
InnoDB: is in the future! Current system log sequence number 42 975484940.
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.1/en/forcing-innodb-recovery.html

我怎樣才能解決這個問題？

您有三 (3) 個選項

選項 #1：使用適當的準備步驟重做 XtraBackup

準備步驟是為了隨身攜帶原木。您必須返回並再次執行備份。

選項#2：強制恢復

與其重新發明輪子，請看我的文章 InnoDB log sequence number is in the future

選項#3：執行多個 rsync

這是相當冒險的，但是您可以對實時 MySQL 實例執行 rsync 多次，直到兩個連續的 rsync 花費相同的時間。然後，在源上關閉 mysql，再執行一個 rsync。然後，經過盡職調查，在新伺服器上啟動 mysql。

請參閱我之前的文章“將來”是否有更好的方法來擺脫 MySQL InnoDB 日誌？

試一試 ！！！

這篇博文描述了一種在沒有and的情況下從frmandibd文件中恢復數據的方法。（當然，這不會恢復僅寫入日誌文件的數據。）該指南有點粗糙，需要在這里和那裡進行調整，但對我有用。ib_logfile0``ib_logfile1

引用自：https://dba.stackexchange.com/questions/60337