遭遇mysql 5.6.10 BUG 一例

mysql 5.6.10 正式发布了，

这几天对innodb_memcache  做了一下测试，在灌数据时候，遭遇bug mysqld 崩溃。

记录一下：

通过 memcached协议 向demo_test 表灌数据

key ： 32字节随机字符串，由于是临时的，没有设计为增序的，所以性能一般

value： 平均20kb 的随机字符。

数据库开的内存15GB

在数据量达到100w笔记录左右的时候，mysqld 连接崩溃了2次，重启后，自动完成恢复。

已经向bugs.mysql.com 提交了bug

http://bugs.mysql.com/bug.php?id=68645


现在上日志：

InnoDB: End of page dump 2013-03-11 10:58:30 7fcc835fe700 InnoDB: uncompressed page, stored checksum in field1 1019541447, calculated checksums for field1: crc32 382723057, innodb 1257528270, none 3735928559, stored checksum in field2 1144184109, calculated checksums for field2: crc32 382723057, innodb 1144184109, none 3735928559, page LSN 7 1175310260, low 4 bytes of LSN at page end 1175310260, page number (if stored to page already) 2325102, space id (if created with >= MySQL-4.1.1 and stored already) 16 InnoDB: Page may be an index page where index id is 32 InnoDB: (index "PRIMARY" of table "test"."demo_test") InnoDB: Corruption of an index tree: table "test"."demo_test", index "PRIMARY", InnoDB: father ptr page no 2410727, child page no 1955328 PHYSICAL RECORD: n_fields 7; compact format; info bits 0  0: len 30; hex d3b0fe1310101010355a69493836364e4f534d546d7948715a727a456e6e; asc         5ZiI866NOSMTmyHqZrzEnn; (total 64 bytes);  1: len 6; hex 000000509c88; asc    P  ;;  2: len 7; hex 890000013b0110; asc     ;  ;;  3: len 30; hex 355a69493836364e4f534d546d7948715a727a456e6e7069596c4f657843; asc 5ZiI866NOSMTmyHqZrzEnnpiYlOexC; (total 788 bytes);  4: len 4; hex 80000000; asc     ;;  5: len 8; hex 0000000000016c22; asc       l";;  6: len 4; hex 80000000; asc     ;;  n_owned: 0; heap_no: 2; next rec: 1019 PHYSICAL RECORD: n_fields 2; compact format; info bits 0  0: len 30; hex d3b0fa1110101010623544306e36554455414975454576632d4a53454630; asc         b5D0n6UDUAIuEEvc-JSEF0; (total 64 bytes);  1: len 4; hex 0024c8e7; asc  $  ;;  n_owned: 0; heap_no: 113; next rec: 7327 InnoDB: You should dump + drop + reimport the table to fix the InnoDB: corruption. If the crash happens at the database startup, see InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html about InnoDB: forcing recovery. Then dump + drop + reimport. 2013-03-11 10:58:30 7fcc835fe700  InnoDB: Assertion failure in thread 140516354156288 in file btr0btr.cc line 1452 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.6/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 02:58:30 UTC - mysqld got signal 6 ; his 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=67108864 read_buffer_size=262144 max_used_connections=2 max_threads=1000 thread_count=2 connection_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 591051 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 0x30000 /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x8f0d25] /usr/local/mysql/bin/mysqld(handle_fatal_signal+0x3e8)[0x66b138] /lib64/libpthread.so.0(+0xf500)[0x7fd0a4ca7500] /lib64/libc.so.6(gsignal+0x35)[0x7fd0a3b548a5] /lib64/libc.so.6(abort+0x175)[0x7fd0a3b56085] /usr/local/mysql/bin/mysqld[0x9e8d49] /usr/local/mysql/bin/mysqld[0x9eb181] /usr/local/mysql/bin/mysqld[0x9eb86a] /usr/local/mysql/bin/mysqld[0x9f7ba3] /usr/local/mysql/bin/mysqld[0x981bfe] /usr/local/mysql/bin/mysqld[0x985f20] /usr/local/mysql/bin/mysqld[0x9864a9] /usr/local/mysql/bin/mysqld[0x9e1b80] /usr/local/mysql/lib/plugin//innodb_engine.so(innodb_api_insert+0x155)[0x7fd0a01053e5] /usr/local/mysql/lib/plugin//innodb_engine.so(innodb_api_store+0x125)[0x7fd0a0106a15] /usr/local/mysql/lib/plugin//innodb_engine.so(+0x8ca1)[0x7fd0a0103ca1] /usr/local/mysql/lib/plugin/libmemcached.so(conn_nread+0x1307)[0x7fd06bb74f17] /usr/local/mysql/lib/plugin/libmemcached.so(+0xb54e)[0x7fd06bb6954e] /usr/local/mysql/lib/plugin/libmemcached.so(event_base_loop+0x379)[0x7fd06bb795f9] /usr/local/mysql/lib/plugin/libmemcached.so(+0x18eb2)[0x7fd06bb76eb2] /lib64/libpthread.so.0(+0x7851)[0x7fd0a4c9f851] /lib64/libc.so.6(clone+0x6d)[0x7fd0a3c0a11d] 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. 130311 10:58:31 mysqld_safe Number of processes running now: 0 130311 10:58:31 mysqld_safe mysqld restarted

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/133735/viewspace-755805/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/133735/viewspace-755805/