Utc-mysqld got Signal 6

Yesterday morning, MySQL came across a strange problem. The database terminated abnormally. After the reboot succeeds, it crashes immediately and does not run properly.

View the MySQL error log as follows:

Innodb:doing recovery:scanned up to log sequence number 1924612226346
121103 21:29:24 innodb:starting An apply batch of logs 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 on 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
Innodb:corruption in the InnoDB tablespace. 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 is because a bug. It is also possible the this binary
Or one of the libraries it was linked against IS corrupt, improperly built,
Or misconfigured. This error can also is caused by malfunctioning hardware.
We'll try our best to scrape up some info, that'll 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 this mysqld could use
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]


has been running normally, today only the problem, so determine the memory configuration is not wrong! Online query to a piece of article: http://www.2cto.com/database/201204/125762.html, and my situation is very similar.

1. Write in/ETC/MY.CNF
[Mysqld]
Innodb_force_recovery = 4
However, it still fails to start.
Instead: Innodb_force_recovery = 6
The database can be read out, in 6 of the case, is unable to modify the database, can not be inserted, only export.

2. Export Data mysqldump-uroot-p123456-r gamedb >/data/backup/gamedb.sql

3, delete the database gamedb or move to the backup directory, and then be sure to reinitialize the database, otherwise the data recovery error log will also indicate that the table space does not have a log file, the database will continue to restart.

4. Start the MySQL service and import the data
Mysql> CREATE DATABASE gamedb default character set UTF8;
mysql> User Gamedb
Mysql> Source/data/backup/gamedb.sql

5, the program and the database operation is normal.


Serious suspicion 5.5.21 version has a bug, I have met two times, a wait io high (http://blog.csdn.net/thomas0yang/article/details/8099515), this time it does not start normally.

Does anyone have a similar experience, or help me with my doubts?

No, lower the version ...

This article is from the "Rookie Fighter" blog, please be sure to keep this source http://linushai.blog.51cto.com/4976486/1746612

Utc-mysqld got Signal 6