mysql cleaned up_关于mysqld自动停止的问题

环境:Os: centos 5.2  DB:mysql-5.1.42 日志如下，请教高手如何解决，谢谢！

----------------------------

END OF INNODB MONITOR OUTPUT

============================

100629 12:25:52  InnoDB: ERROR: over 95 percent of the buffer pool is occupied by

InnoDB: lock heaps or the adaptive hash index! Check that your

InnoDB: transactions do not set too many row locks.

InnoDB: Your buffer pool size is 2048 MB. Maybe you should make

InnoDB: the buffer pool bigger?

InnoDB: We intentionally generate a seg fault to print a stack trace

InnoDB: on Linux!

100629 12:25:52  InnoDB: Assertion failure in thread 1181468992 in file buf/buf0lru.c line 388

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-recovery.html

InnoDB: about forcing recovery.

/usr/sbin/mysqld(print_stacktrace+0x1e)[0x6c90be]

/usr/sbin/mysqld(handle_segfault+0x31d)[0x5b350d]

/lib64/libpthread.so.0[0x385120de80]

/lib64/libc.so.6(gsignal+0x35)[0x3850630155]

/lib64/libc.so.6(abort+0x110)[0x3850631bf0]

/usr/sbin/mysqld(buf_LRU_get_free_block+0x437)[0x72b767]

/usr/sbin/mysqld(buf_frame_alloc+0x9)[0x724369]

/usr/sbin/mysqld(mem_heap_create_block+0x162)[0x76aeb2]

/usr/sbin/mysqld(mem_heap_add_block+0x6b)[0x76af2b]

/usr/sbin/mysqld[0x75810a]

/usr/sbin/mysqld[0x75c039]

/usr/sbin/mysqld[0x75c6b0]

/usr/sbin/mysqld(lock_clust_rec_read_check_and_lock+0xa0)[0x75f8e0]

/usr/sbin/mysqld(row_search_for_mysql+0x744)[0x7946a4]

/usr/sbin/mysqld(_ZN11ha_innobase10index_readEPhPKhj16ha_rkey_function+0x11b)[0x70f33b]

/usr/sbin/mysqld(_ZN7handler16read_range_firstEPK12st_key_rangeS2_bb+0xb7)[0x683de7]

/usr/sbin/mysqld(_ZN7handler21read_multi_range_nextEPP18st_key_multi_range+0x8d)[0x683bcd]

/usr/sbin/mysqld(_ZN18QUICK_RANGE_SELECT8get_nextEv+0x150)[0x674160]

/usr/sbin/mysqld[0x67bf21]

/usr/sbin/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesb+0x875)[0x6352c5]

/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x16f1)[0x5c2ce1]

/usr/sbin/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x122)[0x5c6d12]

/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xef4)[0x5c7cd4]

/usr/sbin/mysqld(_Z10do_commandP3THD+0xc

[0x5c8238]

/usr/sbin/mysqld(handle_one_connection+0x5ea)[0x5bbc9a]

/lib64/libpthread.so.0[0x3851206307]

/lib64/libc.so.6(clone+0x6d)[0x38506d1ded]

100629 12:25:52 - 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=268435456

read_buffer_size=1048576

max_used_connections=52

max_threads=210

threads_connected=22

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 694332 K

bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

thd: 0xb4f9c00

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...

Trying to get some variables.

Some pointers may be invalid and cause the dump to abort...

thd->query at 0x2aab540a0a90  is invalid pointer

thd->thread_id=1630

thd->killed=NOT_KILLED

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.

100629 12:25:53 mysqld_safe Number of processes running now: 0

100629 12:25:53 mysqld_safe mysqld restarted

100629 12:25:53 [Warning] options --log-slow-admin-statements, --log-queries-not-using-indexes and --log-slow-slave-statements have no effect if --log-slow-queries is not set

InnoDB: Log scan progressed past the checkpoint lsn 53 70822724

100629 12:25:55  InnoDB: Database was not shut down normally!

InnoDB: Starting crash recovery.

InnoDB: Reading tablespace information from the .ibd files...

InnoDB: Restoring possible half-written data pages from the doublewrite

InnoDB: buffer...

InnoDB: Doing recovery: scanned up to log sequence number 53 76065280

InnoDB: Doing recovery: scanned up to log sequence number 53 76274080

InnoDB: 2 transaction(s) which must be rolled back or cleaned up

InnoDB: in total 2 row operations to undo

InnoDB: Trx id counter is 3 3211553792

100629 12:25:55  InnoDB: Starting an apply batch of log records to the database...

InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 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

InnoDB: Starting in background the rollback of uncommitted transactions

100629 12:26:00  InnoDB: Rolling back trx with id 3 3211209351, 1 rows to undo

100629 12:26:00  InnoDB: Started; log sequence number 53 76274080

InnoDB: Rolling back of trx id 3 3211209351 completed

100629 12:26:00  InnoDB: Rolling back trx with id 3 3211209346, 1 rows to undo

InnoDB: Rolling back of trx id 3 3211209346 completed

100629 12:26:00  InnoDB: Rollback of non-prepared transactions completed

100629 12:26:00 [Note] Event Scheduler: Loaded 0 events

100629 12:26:00 [Note] /usr/sbin/mysqld: ready for connections.

Version: '5.1.24-rc-community'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL)

100630 15:29:47 [Note] /usr/sbin/mysqld: Normal shutdown

作者: chlotte

发布时间: 2010-07-19