Bug #51083 | Crashing with signal 11 and problems connecting | ||
---|---|---|---|
Submitted: | 11 Feb 2010 10:12 | Modified: | 13 Feb 2010 11:42 |
Reporter: | Peter Hansen | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server | Severity: | S1 (Critical) |
Version: | 5.1.31 | OS: | Linux (ubuntu jaunty) |
Assigned to: | CPU Architecture: | Any |
[11 Feb 2010 10:12]
Peter Hansen
[11 Feb 2010 10:28]
Sveta Smirnova
Thank you for the report. This looks like duplicate of bug #32880 which was fixed in version 5.1.34. Please upgrade to current version 5.1.43, try with it and inform us if this solves the problem.
[11 Feb 2010 10:35]
Peter Hansen
Hi, Thanks for your quick reply. After looking at the bug, I cant tell if the data where recovered or not? Can you tell?
[11 Feb 2010 10:39]
Sveta Smirnova
Thank you for the feedback. After fixing bug #32880 repairing archive table started working again. If this would be recovered in your case depends from corruption which you experienced though. Most likely it will.
[11 Feb 2010 11:00]
Peter Hansen
Okay, ive got newest version on a clone machine running now. Seems not to be crashing now. When running mysqlchk -Asrp --auto-repair dont seem to repair anything? Just tells me to Please do "REPAIR TABLE ...." ? With "error: Corrupt" Should it not repair? Thanks
[11 Feb 2010 11:02]
Peter Hansen
seems only to be ARCHIVE tables that cant be fixed?
[11 Feb 2010 11:09]
Peter Hansen
Manually running "REPAIR TABLE db.eventlog" Just tells me to repair it using REPAIR TABLE... hmm?
[11 Feb 2010 17:00]
Sveta Smirnova
Thank you for the feedback. REPAIR works with ARCHIVE tables. But as I wrote already REPAIR would work only if it can repair a table. This depends from corruption. For example, if some external application erased part of data REPAIR could not do anything. If you think your case is different and REPAIR must repair the table please upload to our FTP server *ARZ, *ARM and *frm files
[12 Feb 2010 13:40]
Peter Hansen
OK, upgraded the server and it seems to work. But we had to delete all archive tables (including data - 300 tables ... ) But.. 5.0 had .ARM files with ARCHIVE tables but they are now deprecated? This then results in error #1010 cant drop database... (cant rmdir ... err 17) Because those files are still present.. why dont mysql check for this before issuing a rmdir command?! Anyway, can i safely delete ALL *.ARM files without any harm?
[13 Feb 2010 11:42]
Sveta Smirnova
Thank you for the feedback. Closing as duplicate of bug #32880 as you can not repeat crash after upgrade. Regarding to your questions: > Because those files are still present.. why dont mysql check for this before issuing a rmdir command?! This was done for purpose: MySQL server can not decide if user left such files per own purpose or just by mistake. So it prefers to delegate this action to the user.