InnoDB: The log sequence number in ibdatafiles does not match the log sequence number in the ib_log

今天做将主库的物理备份恢复到从库的实验时，报错：

[root@slave2 mysql]# service mysql restart

 ERROR! MySQL server PID file could not befound!

Starting MySQL.. ERROR! The server quitwithout updating PID file (/mysql_data1/mysql/data/slave2.pid).

 

查看错误日志：

160704 12:15:34 mysqld_safe Starting mysqlddaemon with databases from /mysql_data1/mysql/data
160704 12:15:34 [Note] Plugin 'FEDERATED'is disabled.
160704 12:15:34 InnoDB: The InnoDB memoryheap is disabled
160704 12:15:34 InnoDB: Mutexes andrw_locks use GCC atomic builtins
160704 12:15:34 InnoDB: Compressed tablesuse zlib 1.2.3
160704 12:15:34 InnoDB: Using Linux nativeAIO
160704 12:15:34 InnoDB: Initializing bufferpool, size = 128.0M
160704 12:15:34 InnoDB: Completedinitialization of buffer pool
160704 12:15:34 InnoDB: highest supportedfile format is Barracuda.
InnoDB: The log sequence number in ibdatafiles does not match
InnoDB: the log sequence number in the ib_logfiles!
160704 12:15:34  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information fromthe .ibd files...
InnoDB: Restoring possible half-writtendata pages from the doublewrite
InnoDB: buffer...
160704 12:15:34  InnoDB: Assertion failure in thread139938876114688 in file fsp0fsp.c line 2101
InnoDB: Failing assertion: inode
InnoDB: We intentionally generate a memorytrap.
InnoDB: Submit a detailed bug report tohttp://bugs.mysql.com.
InnoDB: If you get repeated assertionfailures or crashes, even
InnoDB: immediately after the mysqldstartup, there may be
InnoDB: corruption in the InnoDBtablespace. Please refer to
InnoDB:http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
160704 12:15:34 - mysqld got signal 6 ;
This could be because you hit a bug. It isalso possible that this binary
or one of the libraries it was linkedagainst is corrupt, improperly built,
or misconfigured. This error can also becaused by malfunctioning hardware.
We will try our best to scrape up some infothat will hopefully help diagnose
the problem, but since we have alreadycrashed, something is definitely wrong
and this may fail.
 
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size +sort_buffer_size)*max_threads = 338487 K
bytes of memory
Hope that's ok; if not, decrease somevariables in the equation.
 
Thread pointer: 0x0
Attempting backtrace. You can use thefollowing information to find out
where mysqld died. If you see no messagesafter this, something went
terribly wrong...
stack_bottom = (nil) thread_stack 0x40000
/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x39)[0x799809]
/usr/local/mysql/bin/mysqld(handle_segfault+0x380)[0x4fe300]
/lib64/libpthread.so.0(+0xf710)[0x7f460ebe1710]
/lib64/libc.so.6(gsignal+0x35)[0x7f460dda8925]
/lib64/libc.so.6(abort+0x175)[0x7f460ddaa105]
/usr/local/mysql/bin/mysqld[0x8a8340]
/usr/local/mysql/bin/mysqld[0x8b6375]
/usr/local/mysql/bin/mysqld[0x88445b]
/usr/local/mysql/bin/mysqld[0x833302]
/usr/local/mysql/bin/mysqld[0x80622d]
/usr/local/mysql/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x66be38]
/usr/local/mysql/bin/mysqld[0x57fb6a]
/usr/local/mysql/bin/mysqld(_Z11plugin_initPiPPci+0xb5d)[0x58357d]
/usr/local/mysql/bin/mysqld[0x505dcc]
/usr/local/mysql/bin/mysqld(_Z11mysqld_mainiPPc+0x3ca)[0x50695a]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f460dd94d1d]
/usr/local/mysql/bin/mysqld[0x4fc4da]
The manual page athttp://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find outwhat is causing the crash.

出错原因：

我将数据库文件和ibdata1拷贝错位置了，应该在配置文件中指定的datadir下，却放到了其上层目录下。因此ibdata1和logfile不在同一个目录下。

额外，还要注意检查下数据库文件和ibdata1等文件的owner是否为mysql.