Percona 服务器退出而不更新 PID 文件

Question

Couldn't figure out what's wrong with MySQL server. Error Log is as below. I tried the innodb recovery and removing the files and restarting but it didn't help. 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 doesn't like it when the log file size is different from what it's expecting. If there's a risk that the file has been lost or corrupted, it's probably not usable for data recovery. Rather than risk further damage to your data, MySQL shuts down.

The file size of 5MB is the default. But the size of the log file you have is 32MB. So it's clear that you used to have a configuration that set the log file size to 32MB. Probably someone removed the /etc/my.cnf file, or edited it.

You can edit your /etc/my.cnf and set:

[mysqld]
innodb_log_file_size=33554432

Then restart the MySQL service.

---

"Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files."

This is pretty self-explanatory. I suspect you (or someone else) tried to move files around without understanding MySQL. If you have a recent backup, you could remove the ibdata1 and ib_logfile* , start MySQL, and then restore your backup.

If you don't have a backup, you need a MySQL consultant who can fix this. I recommend https://twindb.com/mysql-data-recovery/ or https://www.percona.com/solutions/fix/data-recovery to get expert help.

Answer 2

try to add following into /etc/my.cnf

[mysqld] ...

innodb_force_recovery = 1