Description:
Hi~~!!
mySQL Server : Total Momory 16GB
Dual-Core AMD Opteron(tm) Processor 8220 (x 8)
##########
# my.cnf #
##########
[client]
port = 3306
socket = /tmp/mysql.sock
[mysqld]
datadir=/data
skip-locking
long_query_time=1
log-slow-queries=/dblog/mysql1-slow.log
max_binlog_size=512000000
max_connections=3000
max_connect_errors=1000
max_allowed_packet=100M
table_cache=10000
sort_buffer=8M
join_buffer=8M
read_buffer_size=8M
read_rnd_buffer_size=8M
thread_cache=10000
thread_concurrency=8
wait_timeout=10
default-character-set=euckr
language=korean
expire_logs_days=60
#query_prealloc_size = 100M
#query_alloc_block_size = 1000M
#range_alloc_block_size = 1000M
#query_cache_size = 0
query_cache_size = 512M : query_cache_size
#query_cache_min_res_unit = 1024
tmp_table_size = 4M
tmpdir=/mysql_temp/
#max_heap_table_size=2000M
max_tmp_tables=100000
#innodb#
innodb_thread_concurrency=32
innodb_data_home_dir = /data/
innodb_data_file_path = ibdata1:2000M:autoextend
innodb_log_group_home_dir = /dblog/innodb/
innodb_log_arch_dir = /dblog/innodb/
innodb_log_files_in_group=5
innodb_buffer_pool_size=8000M
innodb_additional_mem_pool_size=100M
innodb_log_file_size=512M
innodb_log_buffer_size=96M
innodb_flush_log_at_trx_commit=0
innodb_lock_wait_timeout=10
innodb_flush_method='O_DIRECT'
#tx_isolation=READ-COMMITTED
innodb_locks_unsafe_for_binlog=1
innodb_open_files=100000
innodb_file_per_table=1
#innodb_force_recovery=1
# comment by tokky (20071206)
#memlock
#log-long-format
#for preload key cache
#cold_cache.key_buffer_size = 2G
#server-id = 1
#Dual Master
#master-host = 192.168.10.75
#master-user = replica
#master-password = skf.wkanfk
#master-port = 3306
##binlog-ignore-db = dbmsg
#for debugging
#log=query-log
[myisamchk]
key_buffer=300M
sort_buffer=30M
read_buffer=10M
write_buffer=10M
[mysqldump]
quick
max_allowed_packet=16M
default-character-set=euckr
[mysql]
no-auto-rehash
default-character-set=euckr
[mysqli]
no-auto-rehash
default-character-set=euckr
##################
# error Messages #
##################
mysqld got signal 11;
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=8388600
read_buffer_size=8384512
max_used_connections=193
max_connections=3000
threads_connected=17
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 49148168 Kbytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x2cd9d41f30
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...
Cannot determine thread, fp=0x47a6e0a8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
Stack trace seems successful - bottom reached
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace.
Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x129629b0 = UPDATE TB_HP_HOMPY_COUNT_5
SET gbook_count = IF(0 > gbook_count + ?, 0, gbook_count + ?)
WHERE master_id = ?
thd->thread_id=200107516
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
mysqld: my_new.cc:50: int __cxa_pure_virtual(): Assertion `"Pure virtual method called." == "Aborted"' failed.
Fatal signal 6 while backtracing
mysqld: my_new.cc:50: int __cxa_pure_virtual(): Assertion `"Pure virtual method called." == "Aborted"' failed.
Number of processes running now: 0
100322 20:35:08 mysqld restarted
100322 20:35:11 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...
100322 20:35:14 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 421 963108924.
InnoDB: Doing recovery: scanned up to log sequence number 421 968351744
InnoDB: Doing recovery: scanned up to log sequence number 421 973594624
...
InnoDB: Doing recovery: scanned up to log sequence number 421 1534582784
InnoDB: Doing recovery: scanned up to log sequence number 421 1534651140
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is 1 1247069952
100322 20:37:16 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: Last MySQL binlog file position 0 109269238, file name /dblog/binlog/mysql1-bin.000106
InnoDB: Starting in background the rollback of uncommitted transactions
100322 21:06:42 InnoDB: Rolling back trx with id 1 1247069655, 1 rows to undo
100322 21:06:42 InnoDB: Started; log sequence number 421 1534651140
100322 21:06:42 [Note] Recovering after a crash using /dblog/binlog/mysql1-bin
InnoDB: Rolling back of trx id 1 1247069655 completed
100322 21:06:42 InnoDB: Rollback of non-prepared transactions completed
100322 21:06:43 [Note] Starting crash recovery...
100322 21:06:43 [Note] Crash recovery finished.
How to repeat:
suddenly & rarely
Description: Hi~~!! mySQL Server : Total Momory 16GB Dual-Core AMD Opteron(tm) Processor 8220 (x 8) ########## # my.cnf # ########## [client] port = 3306 socket = /tmp/mysql.sock [mysqld] datadir=/data skip-locking long_query_time=1 log-slow-queries=/dblog/mysql1-slow.log max_binlog_size=512000000 max_connections=3000 max_connect_errors=1000 max_allowed_packet=100M table_cache=10000 sort_buffer=8M join_buffer=8M read_buffer_size=8M read_rnd_buffer_size=8M thread_cache=10000 thread_concurrency=8 wait_timeout=10 default-character-set=euckr language=korean expire_logs_days=60 #query_prealloc_size = 100M #query_alloc_block_size = 1000M #range_alloc_block_size = 1000M #query_cache_size = 0 query_cache_size = 512M : query_cache_size #query_cache_min_res_unit = 1024 tmp_table_size = 4M tmpdir=/mysql_temp/ #max_heap_table_size=2000M max_tmp_tables=100000 #innodb# innodb_thread_concurrency=32 innodb_data_home_dir = /data/ innodb_data_file_path = ibdata1:2000M:autoextend innodb_log_group_home_dir = /dblog/innodb/ innodb_log_arch_dir = /dblog/innodb/ innodb_log_files_in_group=5 innodb_buffer_pool_size=8000M innodb_additional_mem_pool_size=100M innodb_log_file_size=512M innodb_log_buffer_size=96M innodb_flush_log_at_trx_commit=0 innodb_lock_wait_timeout=10 innodb_flush_method='O_DIRECT' #tx_isolation=READ-COMMITTED innodb_locks_unsafe_for_binlog=1 innodb_open_files=100000 innodb_file_per_table=1 #innodb_force_recovery=1 # comment by tokky (20071206) #memlock #log-long-format #for preload key cache #cold_cache.key_buffer_size = 2G #server-id = 1 #Dual Master #master-host = 192.168.10.75 #master-user = replica #master-password = skf.wkanfk #master-port = 3306 ##binlog-ignore-db = dbmsg #for debugging #log=query-log [myisamchk] key_buffer=300M sort_buffer=30M read_buffer=10M write_buffer=10M [mysqldump] quick max_allowed_packet=16M default-character-set=euckr [mysql] no-auto-rehash default-character-set=euckr [mysqli] no-auto-rehash default-character-set=euckr ################## # error Messages # ################## mysqld got signal 11; 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=8388600 read_buffer_size=8384512 max_used_connections=193 max_connections=3000 threads_connected=17 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 49148168 Kbytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x2cd9d41f30 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... Cannot determine thread, fp=0x47a6e0a8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) Stack trace seems successful - bottom reached Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x129629b0 = UPDATE TB_HP_HOMPY_COUNT_5 SET gbook_count = IF(0 > gbook_count + ?, 0, gbook_count + ?) WHERE master_id = ? thd->thread_id=200107516 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. mysqld: my_new.cc:50: int __cxa_pure_virtual(): Assertion `"Pure virtual method called." == "Aborted"' failed. Fatal signal 6 while backtracing mysqld: my_new.cc:50: int __cxa_pure_virtual(): Assertion `"Pure virtual method called." == "Aborted"' failed. Number of processes running now: 0 100322 20:35:08 mysqld restarted 100322 20:35:11 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... 100322 20:35:14 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 421 963108924. InnoDB: Doing recovery: scanned up to log sequence number 421 968351744 InnoDB: Doing recovery: scanned up to log sequence number 421 973594624 ... InnoDB: Doing recovery: scanned up to log sequence number 421 1534582784 InnoDB: Doing recovery: scanned up to log sequence number 421 1534651140 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 1 row operations to undo InnoDB: Trx id counter is 1 1247069952 100322 20:37:16 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: Last MySQL binlog file position 0 109269238, file name /dblog/binlog/mysql1-bin.000106 InnoDB: Starting in background the rollback of uncommitted transactions 100322 21:06:42 InnoDB: Rolling back trx with id 1 1247069655, 1 rows to undo 100322 21:06:42 InnoDB: Started; log sequence number 421 1534651140 100322 21:06:42 [Note] Recovering after a crash using /dblog/binlog/mysql1-bin InnoDB: Rolling back of trx id 1 1247069655 completed 100322 21:06:42 InnoDB: Rollback of non-prepared transactions completed 100322 21:06:43 [Note] Starting crash recovery... 100322 21:06:43 [Note] Crash recovery finished. How to repeat: suddenly & rarely