mysql不斷崩潰損壞的數據庫

我已經嘗試解決這個問題大約 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/ / .MYI
• mysqlcheck -u root -p –auto-repair -c -o –all-databases

使用 mysqlcheck 時，它給了我與下麵類似的錯誤消息，並不是每個數據庫都損壞了，但是那些有大量損壞的表的數據庫：

joomla.e6dh5_utf8_conversion
Error    : Unknown collation '#224' in table 'e6dh5_utf8_conversion' definition
error    : Corrupt

一切都沒有成功……因為我之前備份了我的數據庫，我認為我會“刪除”損壞的數據庫，MYsql 甚至不會讓我這樣做！

有沒有人可以提供幫助？

• 美分 - 美分 6.9
• MySQL - mysql-server-5.1.73-8.el6_8.x86_64

您的數據庫有Unknown collation錯誤。這意味著您安裝的 MySQL 版本比崩潰前使用的舊版本。

您需要安裝崩潰前使用的更新版本的 MySQL 或Percona 儲存庫中的最新版本 MariaDB 。

在通過命令安裝新版本之前不要忘記刪除舊版本的mysql：

# yum remove mysql mysql-server

引用自：https://serverfault.com/questions/846308