Percona服務器退出時未更新PID文件

Question

無法找出MySQL服務器出了什麼問題。錯誤日誌如下。我嘗試了innodb恢復和刪除文件並重新啓動，但它沒有幫助。 http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

InnoDB: Serious error! InnoDB is trying to free page 1344 
InnoDB: though it is already marked as free in the tablespace! 
InnoDB: The tablespace free space info is corrupt. 
InnoDB: You may need to dump your InnoDB tables and recreate the whole 
InnoDB: database! 
InnoDB: Please refer to 
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html 
InnoDB: about forcing recovery. 
160805 9:43:22 InnoDB: Assertion failure in thread 139839724754688 in file fsp0fsp.c line 3329 
InnoDB: We intentionally generate a memory trap. 
InnoDB: Submit a detailed bug report to http://bugs.mysql.com. 
InnoDB: If you get repeated assertion failures or crashes, even 
InnoDB: immediately after the mysqld startup, there may be 
InnoDB: corruption in the InnoDB tablespace. Please refer to 
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html 
InnoDB: about forcing recovery. 
16:43:22 UTC - mysqld got signal 6 ; 
This could be because you hit a bug. It is also possible that this binary 
or one of the libraries it was linked against is corrupt, improperly built, 
or misconfigured. This error can also be caused by malfunctioning hardware. 
We will try our best to scrape up some info that will hopefully help 
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail. 
Please help us make Percona Server better by reporting any 
bugs at http://bugs.percona.com/ 

key_buffer_size=8388608 
read_buffer_size=131072 
max_used_connections=0 
max_threads=153 
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 = 343009 K bytes of memory 
Hope that's ok; if not, decrease some variables in the equation. 

Thread pointer: 0x0 
Attempting backtrace. You can use the following information to find out 
where mysqld died. If you see no messages after this, something went 
terribly wrong... 
stack_bottom = 0 thread_stack 0x40000 
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x7ce5a5] 
/usr/sbin/mysqld(handle_fatal_signal+0x4b4)[0x6a2f54] 
/lib64/libpthread.so.0(+0xf7e0)[0x7f2f139367e0] 
/lib64/libc.so.6(gsignal+0x35)[0x7f2f11f915e5] 
/lib64/libc.so.6(abort+0x175)[0x7f2f11f92dc5] 
/usr/sbin/mysqld[0x919d97] 
/usr/sbin/mysqld[0x91a148] 
/usr/sbin/mysqld[0x8bb858] 
/usr/sbin/mysqld[0x97b427] 
/usr/sbin/mysqld[0x97b9d8] 
/usr/sbin/mysqld[0x96f907] 
/usr/sbin/mysqld[0x88e7a7] 
/usr/sbin/mysqld[0x882d6c] 
/lib64/libpthread.so.0(+0x7aa1)[0x7f2f1392eaa1] 
/lib64/libc.so.6(clone+0x6d)[0x7f2f12047aad] 
You may download the Percona Server operations manual by visiting 
http://www.percona.com/software/percona-server/. You may find information 
in the manual which will help you identify the cause of the crash. 
160805 09:43:22 mysqld_safe mysqld from pid file /var/lib/mysql/websult.arvixevps.com.pid ended 

Answer 1

InnoDB: Error: log file ./ib_logfile0 is of different size 0 33554432 bytes 
InnoDB: than specified in the .cnf file 0 5242880 bytes! 

的InnoDB當日志文件的大小是從什麼它期待不同不喜歡它。如果存在文件丟失或損壞的風險，則可能無法用於數據恢復。 MySQL不會對數據造成進一步的損害，而是會關閉MySQL。

文件大小爲5MB是默認值。但是你的日誌文件的大小是32MB。所以很顯然你使用有一個配置，將日誌文件大小設置爲32MB。可能有人刪除了/etc/my.cnf文件，或對其進行了編輯。

您可以編輯您的/etc/my.cnf，並設置：

[mysqld] 
innodb_log_file_size=33554432 

然後重啓MySQL服務。

---

「你的數據庫可能已損壞，或者您可能複製InnoDB的InnoDB的：表而不是InnoDB的日誌文件」

這很好理解。我懷疑你（或其他人）試圖在不理解MySQL的情況下移動文件。如果您有最近的備份，可以刪除ibdata1和ib_logfile*，啓動MySQL，然後恢復備份。

如果您沒有備份，您需要一位能夠解決此問題的MySQL顧問。我建議https://twindb.com/mysql-data-recovery/或https://www.percona.com/solutions/fix/data-recovery獲得專家的幫助。