mysql 5.6.10 正式釋出了，

這幾天對innodb_memcache 做了一下測試，在灌資料時候，遭遇bug mysqld 崩潰。

記錄一下：

透過 memcached協議向demo_test 表灌資料

key ： 32位元組隨機字串，由於是臨時的，沒有設計為增序的，所以效能一般

value：平均20kb 的隨機字元。

資料庫開的記憶體15GB

在資料量達到100w筆記錄左右的時候，mysqld 連線崩潰了2次，重啟後，自動完成恢復。

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

現在上日誌：

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

遭遇mysql 5.6.10 BUG 一例

相關文章