Description:
mysqld crashed without backtrace. MySQL log:
100709 10:39:14 [Note] Plugin 'FEDERATED' is disabled.
100709 10:39:16 InnoDB: Started; log sequence number 5 2069556409
100709 10:39:17 [Note] Event Scheduler: Loaded 0 events
100709 10:39:17 [Note] c:\licstat_deploy_test\mysql\mysqld.exe: ready for connections.
Version: '5.1.37-community-log' socket: '' port: 3306 MySQL Community Server (GPL)
100709 14:12:08 InnoDB: Operating system error number 995 in a file operation.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
InnoDB: File name innodb_data\ibdata1
InnoDB: File operation call: 'Windows aio'.
InnoDB: Cannot continue operation.
100709 14:12:08 - mysqld got exception 0x80000003 ;
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=67108864
read_buffer_size=4194304
max_used_connections=19
max_threads=151
threads_connected=6
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1303481 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0x279aa000
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...
It's running on virtual machine with 4-core 2,33 GHz CPU with 4GB RAM. All tables are in InnoDB engine, we also create temporary MEMORY tables. It stores about 100 milion records. MySQL config file:
[mysqld]
bind-address = 127.0.0.1
log-error = ../../log/mysql.log
slow_query_log = 1
long_query_time = 1
log-output = FILE
slow-query-log-file = ../../log/mysql_slow.log
sql_mode = STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_UNSIGNED_SUBTRACTION
max_sp_recursion_depth = 20
socket = mysql.sock
skip-locking
key_buffer_size = 64M
max_allowed_packet = 10M
table_open_cache = 256
sort_buffer_size = 4M
read_buffer_size = 4M
join_buffer_size = 4M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
binlog_cache_size = 8M
thread_stack = 256K
thread_concurrency = 4
innodb_thread_concurrency = 4
innodb_data_home_dir = innodb_data/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = innodb_data/
innodb_buffer_pool_size = 512M
innodb_additional_mem_pool_size = 8M
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
innodb_lock_wait_timeout = 600
innodb_rollback_on_timeout = 1
[mysqldump]
quick
max_allowed_packet = 16M
[myisamchk]
key_buffer_size = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout
How to repeat:
Unfortunately I don't have the query that broke database, but it was one of usually working ones. Our application was just working, no analyze/backup activity was taking place.
Suggested fix:
If it's possible log more informative error message.
