>> Greetings all. >> >> I have a bit of a problem here, a database i'm administering was somehow = >> corrupted, and i'm unable to recover it in any way. > >what happened? A power outage? You deleted the ib_logfiles? Modified my.cnf? >Hard disk broke?
Thats the weird thing, nothing abnormal happened, i just saw the mysqld using a lot of resources and shut it down. I suppose it must have been a query, or the database beeing to large or something. >What does uname -a say about the Linux kernel in Debian-unstable? It says its running a 2.4.19 kernel, i686 on GNU/Linux >> Is there any way at = >> all to recover a corrupt InnoDB database? (I read on innodb.com that it = >> is impossible, but hope it is not) > >You should always take backups of valuable data, and also keep the MySQL >binlog so that you can replay the modifications after the backup. So i understand, i'm used to running MyISAM tables, and have never had any problems with data corruption before now. Nothing a good myisamchk couldent fix anyhow. I do have a backup, just not old enough. I've been on vacation, so therefore the data got rotate out the system and overwritten. I only have corruptet backups. >> When I run a query from any InnoDB table in the database MySQL crashes = >> with the following stack trace and errors.=20 > >Did you resolve the stack trace with the right mysqld.sym file? The trace >below is nonsensical. I think so, but i'll have to get back to you with that. >What is the query? What query? The one that triggers the segfault below is any SELECT, SHOW TABLE STATUS or what ever reads the files. >What is the complete .err log? I cannot find any entry in the error before i restartet the mysql process, then it complained the below. > I'm running a GNU/Linux system and MySQL 4.0.13 from the Debian = > unstable. > > Error: trying to access field 4294967295 in rec > 030807 13:53:24 InnoDB: Assertion failure in thread 180234 in file = > rem0rec.c line 111 > InnoDB: Failing assertion: 0 > ... > thd=3D0x86e3990 > 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=3D0xbe7fe898, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x8102bc3 > 0x401ad75a > 0x82b9a60 > 0x8230d50 > 0x822e42c > 0x816952f > 0x8169c84 > 0x816bf6a > 0x816c2be > 0x815e77f > 0x8178c60 > 0x810f8e8 > 0x8112a15 > 0x810db3d > 0x810d6cc > 0x810d059 > 0x401a7d53 > 0x4038a3f7 > New value of fp=3D(nil) failed sanity check, terminating stack trace! > ... > 0x8102bc3 mysql_binlog_send__FP3THDPcUxUs + 1419 > 0x401ad75a _end + 936375294 > 0x82b9a60 _tr_flush_block + 640 > 0x8230d50 page_cur_delete_rec + 5780 > 0x822e42c page_copy_rec_list_end_to_created_page + 392 > 0x816952f yyparse + 3855 > 0x8169c84 yylex + 1572 > 0x816bf6a opt_search_plan_for_table + 742 > 0x816c2be opt_search_plan_for_table + 1594 > 0x815e77f row_upd_clust_step + 431 > 0x8178c60 btr_compress + 3852 > 0x810f8e8 srv_master_thread + 172 > 0x8112a15 innobase_start_or_create_for_mysql + 1297 > 0x810db3d srv_sprintf_innodb_monitor + 425 > 0x810d6cc srv_suspend_mysql_thread + 1372 > 0x810d059 srv_table_reserve_slot_for_mysql + 473 > 0x401a7d53 _end + 936352247 > 0x4038a3f7 _end + 938328219 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
