昨天上午mysql又碰到一個奇怪的問題。數據庫異常終止。重啟成功后過就馬上崩潰，不能正常運行。

查看mysql錯誤日志如下：

InnoDB: Doing recovery: scanned up to log sequence number 1924612226346

121103 21:29:24? InnoDB: Starting an apply batch of log records to the database...

InnoDB: Progress in percents: 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99

InnoDB: Apply batch completed

121103 21:29:42? InnoDB: Waiting for the background threads to start

121103 21:29:43 InnoDB: 1.1.8 started; log sequence number 1924612226346

121103 21:29:43 [Note] Event Scheduler: Loaded 0 events

121103 21:29:43 [Note] /usr/sbin/mysqld: ready for connections.

Version: '5.5.21-log'? socket: '/var/run/mysqld/mysqld.sock'? port: 3306? Source distribution

121103 21:29:44? InnoDB: Assertion failure in thread 140444553848592 in file trx0purge.c line 829

InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no

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.

13:29:44 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=8388608

read_buffer_size=8388608

max_used_connections=10

max_threads=100

thread_count=10

connection_count=10

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1238130 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+0x2e)[0x76d27e]

一直都運行正常，今天才出現問題了，所以判斷內存方面的配置是沒有錯誤的！網上查詢到一片文章：http://www.2cto.com/database/201204/125762.html，跟我的情況很相似。

1、在/etc/my.cnf中寫入

[mysqld]

innodb_force_recovery = 4

但是仍然無法啟動。

改為：innodb_force_recovery = 6

數據庫可以讀出來，在6的情況下，是無法修改數據庫的，也無法插入，只能導出。

2、導出數據 mysqldump -uroot -p123456 -R gamedb > /data/backup/gamedb.sql

3、刪除數據庫gamedb或者移到備份目錄下面，然后一定要重新初始化數據庫，否則數據恢復了錯誤日志里也會提示表空間沒有日志文件，數據庫也會不斷重啟。

4、啟動mysql服務，導入數據

mysql> create database gamedb default character set utf8;

mysql> user gamedb

mysql> source /data/backup/gamedb.sql

5、程序和數據庫運行正常。

嚴重懷疑5.5.21版本有bug，我已經碰到兩次了，一次wait IO高(http://blog.csdn.net/thomas0yang/article/details/8099515)，這次又不能正常啟動。

請問誰有類似經歷，或者幫我解惑呢？

不行降低版本了。。。

總結

以上是生活随笔為你收集整理的mysql got signal 6_UTC - mysqld got signal 6的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。