Bug #51408 | MyISAM crash during enable_indexes at unlink_block | ||
---|---|---|---|
Submitted: | 23 Feb 2010 3:20 | Modified: | 1 Jul 2010 18:41 |
Reporter: | James Day | Email Updates: | |
Status: | No Feedback | Impact on me: | |
Category: | MySQL Server: MyISAM storage engine | Severity: | S2 (Serious) |
Version: | 5.0.60sp1 | OS: | Linux (2.6.18-164.el5 #1 SMP) |
Assigned to: | CPU Architecture: | Any |
[23 Feb 2010 3:20]
James Day
[19 Mar 2010 2:20]
Mark Callaghan
I get a similar crash in 5.1.45 using sysbench sbtest table. The basic reproduction case is: 1) create table without indexes 2) insert 40M rows from another table 3) alter table add indexes 4) get disk full errors 4) hit control-C error log output: 100318 18:13:23 [ERROR] /data/5145fb/libexec/mysqld: The table 'sbtest' is full 100318 19:09:02 [ERROR] /data/5145fb/libexec/mysqld: Disk is full writing './testm/#sql-452b_df.MYD' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space) 100318 19:09:02 [ERROR] /data/5145fb/libexec/mysqld: Retry in 60 secs. Message reprinted in 600 secs 100318 19:13:02 [ERROR] /data/5145fb/libexec/mysqld: Incorrect key file for table './testm/#sql-452b_df.MYI'; try to repair it 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 = 0x41b150e0 thread_stack 0x40000 /data/5145fb/libexec/mysqld(my_print_stacktrace+0x2e) [0x87953e] /data/5145fb/libexec/mysqld(handle_segfault+0x31d) [0x5973fd] /lib64/libpthread.so.0 [0x34bdc0de70] /data/5145fb/libexec/mysqld [0x879f00] /data/5145fb/libexec/mysqld [0x879f82] /data/5145fb/libexec/mysqld [0x87ac67] /data/5145fb/libexec/mysqld(flush_key_blocks+0x6f) [0x87c7df] /data/5145fb/libexec/mysqld(flush_blocks+0x25) [0x7fb5e5] /data/5145fb/libexec/mysqld(mi_repair_by_sort+0x162) [0x7fca22] /data/5145fb/libexec/mysqld(ha_myisam::repair(THD*, st_mi_check_param&, bool)+0x6cf) [0x7dd90f] /data/5145fb/libexec/mysqld(ha_myisam::enable_indexes(unsigned int)+0x114) [0x7dda94] /data/5145fb/libexec/mysqld(ha_myisam::end_bulk_insert()+0x61) [0x7defd1] /data/5145fb/libexec/mysqld(mysql_alter_table(THD*, char*, char*, st_ha_create_information*, TABLE_LIST*, Alter_info*, unsigned int, st_ord er*, bool)+0x2356) [0x683856] /data/5145fb/libexec/mysqld(mysql_execute_command(THD*, unsigned long long*)+0x28ae) [0x5a70ce] /data/5145fb/libexec/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**, unsigned long long*)+0x239) [0x5aa5d9] /data/5145fb/libexec/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x45b) [0x5aaa7b] /data/5145fb/libexec/mysqld(do_command(THD*)+0xe7) [0x5abbe7] /data/5145fb/libexec/mysqld(handle_one_connection+0x55f) [0x59e37f] /lib64/libpthread.so.0 [0x34bdc062f7] /lib64/libc.so.6(clone+0x6d) [0x34bd0d1e3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0xcb004c0 = alter table sbtest add primary key(id), add index k(k) thd->thread_id=223 thd->killed=KILL_QUERY my.cnf settings: [mysqld] plugin-load=libpbxt.so pbxt pbxt_index_cache_size=250M pbxt_record_cache_size=750M innodb_buffer_pool_size=1000M innodb_log_file_size=100M innodb_flush_log_at_trx_commit=2 innodb_doublewrite=0 # innodb_flush_method=O_DIRECT innodb_thread_concurrency=0 max_connections=2000 table_cache=2000 innodb_max_dirty_pages_pct=80 key_buffer_size=1000M table DDL before adding indexes: | sbtest | CREATE TABLE `sbtest` ( `id` int(10) unsigned NOT NULL DEFAULT '0', `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '' ) ENGINE=MyISAM DEFAULT CHARSET=latin1 | alter table statement alter table sbtest add primary key(id), add index k(k);
[1 Jun 2010 18:41]
Sveta Smirnova
Mark, thank you for the feedback. Could you please try 5.1.47 in your environment: I was not able to repeat the problem using this version.
[1 Jul 2010 23:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".