我已经尝试解决这个问题大约 8 个小时了。
由于不相关的问题，我不得不删除 mysql 并重新安装它。从那时起，mysql 每 2-3 秒就会崩溃并重新启动一次，mysql 日志中会出现以下内容。
170425 3:52:53 InnoDB: Assertion failure in thread 140306907342592 in file handler/ha_innodb.cc line 875
InnoDB: Failing assertion: cset == 0
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.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
19:52:53 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.
key_buffer_size=8384512
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 = 338336 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/libexec/mysqld(my_print_stacktrace+0x29) [0x850ca9]
/usr/libexec/mysqld(handle_fatal_signal+0x483) [0x6a4143]
/lib64/libpthread.so.0() [0x3010c0f7e0]
/lib64/libc.so.6(gsignal+0x35) [0x3010832495]
/lib64/libc.so.6(abort+0x175) [0x3010833c75]
/usr/libexec/mysqld() [0x72d9db]
/usr/libexec/mysqld(dict_mem_table_add_col+0x20e) [0x76080e]
/usr/libexec/mysqld(dict_load_table+0x99e) [0x75c1be]
/usr/libexec/mysqld(dict_load_table_on_id+0x403) [0x75cf43]
/usr/libexec/mysqld(row_purge_step+0x39c) [0x7b383c]
/usr/libexec/mysqld(que_run_threads+0x55b) [0x7a278b]
/usr/libexec/mysqld(trx_purge+0x332) [0x7ccb32]
/usr/libexec/mysqld(srv_master_thread+0x708) [0x7c54c8]
/lib64/libpthread.so.0() [0x3010c07aa1]
/lib64/libc.so.6(clone+0x6d) [0x30108e8bcd]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
170425 03:52:53 mysqld_safe Number of processes running now: 0
170425 03:52:53 mysqld_safe mysqld restarted
170425 3:52:53 InnoDB: Initializing buffer pool, size = 8.0M
170425 3:52:53 InnoDB: Completed initialization of buffer pool
170425 3:52:53 InnoDB: Started; log sequence number 1 648020427
170425 3:52:53 [Note] Event Scheduler: Loaded 0 events
170425 3:52:53 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.73' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
我尝试了几种方法来修复数据库，包括：
- myisamchk --silent --force --fast --update-state /var/lib/mysql//。我的我
- mysqlcheck -u root -p --自动修复 -c -o --所有数据库
当使用 mysqlcheck 时，它会给我类似下面的错误消息，并且不是每个数据库都已损坏，但是损坏的数据库有大量损坏的表：
joomla.e6dh5_utf8_conversion
Error : Unknown collation '#224' in table 'e6dh5_utf8_conversion' definition
error : Corrupt
一切都没有成功...由于我之前备份了数据库，我想我会“删除”损坏的数据库，但 MYsql 甚至不允许我这样做！！
有谁可以帮忙吗？
- Centos——Centos 6.9
- MySQL-mysql-服务器-5.1.73-8.el6_8.x86_64
答案1
您的数据库有Unknown collation错误。这意味着您安装的 MySQL 版本比崩溃前使用的版本要旧。
您需要安装崩溃前使用的较新版本的 MySQL 或最新版本的 MariaDBPercona 的存储库。
在安装新版本之前，不要忘记删除旧版本的 mysql，命令如下：
# yum remove mysql mysql-server