mysql got signal 6_UTC - mysqld got signal 6
昨天上午mysql又碰到一個(gè)奇怪的問(wèn)題。數(shù)據(jù)庫(kù)異常終止。重啟成功后過(guò)就馬上崩潰，不能正常運(yùn)行。
查看mysql錯(cuò)誤日志如下：
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]
一直都運(yùn)行正常，今天才出現(xiàn)問(wèn)題了，所以判斷內(nèi)存方面的配置是沒(méi)有錯(cuò)誤的！網(wǎng)上查詢到一片文章：http://www.2cto.com/database/201204/125762.html，跟我的情況很相似。
1、在/etc/my.cnf中寫入
[mysqld]
innodb_force_recovery = 4
但是仍然無(wú)法啟動(dòng)。
改為：innodb_force_recovery = 6
數(shù)據(jù)庫(kù)可以讀出來(lái)，在6的情況下，是無(wú)法修改數(shù)據(jù)庫(kù)的，也無(wú)法插入，只能導(dǎo)出。
2、導(dǎo)出數(shù)據(jù) mysqldump -uroot -p123456 -R gamedb > /data/backup/gamedb.sql
3、刪除數(shù)據(jù)庫(kù)gamedb或者移到備份目錄下面，然后一定要重新初始化數(shù)據(jù)庫(kù)，否則數(shù)據(jù)恢復(fù)了錯(cuò)誤日志里也會(huì)提示表空間沒(méi)有日志文件，數(shù)據(jù)庫(kù)也會(huì)不斷重啟。
4、啟動(dòng)mysql服務(wù)，導(dǎo)入數(shù)據(jù)
mysql> create database gamedb default character set utf8;
mysql> user gamedb
mysql> source /data/backup/gamedb.sql
5、程序和數(shù)據(jù)庫(kù)運(yùn)行正常。
嚴(yán)重懷疑5.5.21版本有bug，我已經(jīng)碰到兩次了，一次wait IO高(http://blog.csdn.net/thomas0yang/article/details/8099515)，這次又不能正常啟動(dòng)。
請(qǐng)問(wèn)誰(shuí)有類似經(jīng)歷，或者幫我解惑呢？
不行降低版本了。。。
總結(jié)
以上是生活随笔為你收集整理的mysql got signal 6_UTC - mysqld got signal 6的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： mysql etc rc.local_C
- 下一篇： mysql 索引生命周期_MYSQL 索