Bug #20233 Server should log corrupted table info when error is found via libmysql
Submitted: 2 Jun 2006 16:11 Modified: 11 Aug 2006 17:19
Reporter: [ name withheld ] Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:4.1.18 OS:Linux (RedHat 9)
Assigned to: CPU Architecture:Any

[2 Jun 2006 16:11] [ name withheld ]
Description:
I have a large merge table that had one of its member tables become corrupted after a server crash.

My apologies if this is classified incorrectly as a server problem, but that's where it seems like the problem lies.

A perl script using DBD::mysql interacting with that merge table returned the error:

DBD::mysql::st execute failed: Can't open file: 'mailer_mailsent.MRG' (errno: 145) at ...

However that error never was logged in the server error log. I suspect that this may also be the case with other programs which interact with the server via libmysql (php, etc)

Interacting with the server via the mysql command shell trying to access that table properly inserts a error in the server error log like:

060601 21:42:11 [ERROR] /usr/sbin/mysqld: Can't open file: 'mailer_mailsent.MRG' (errno: 145)

Basically if the server knows a table is corrupt when it tries to access something then it should log an error no matter how that interaction occurs.

We have automated tools which are monitoring the error logs of our mysql servers alert us if errors occur. Scripts which run that trigger such errors are just as important to be logged as those which we encounter via the mysql command line.

How to repeat:
1) Create a merge table
2) Corrupt the index of one of the member tables of that merge table such that it results in an errno: 145 as above when you attempt to access it.
3) Connect to the server via the mysql> shell and issue a 'DESCRIBE tablename' of the merge table.
4) Observe the line in the server log corresponding to that DESCRIBE statement.
5) Create a perl script using DBD::mysql that connects to the server and issues a 'DESCRIBE tablename' command of the  merge table.
6) Observe that no error output is logged by the server.

Suggested fix:
Make sure that when the server encounters an error it logs it no matter how the interaction with the server occurs that triggers the error (mysql command shell, DBD::mysql, php, etc)
[29 Jun 2006 14:09] Valeriy Kravchuk
Thank you for a problem report. Please, provide more details on how to repeat, namely, what shell I do to get error 145 for MERGE table. 

Please, also try to repeat with a newer version of MySQL, 4.1.20. Inform about the results.
[5 Jul 2006 21:55] [ name withheld ]
Unfortunately I have no way of knowing how to recreate the error 145 type of corruption as it was the result of a non-graceful system crash. I'm not entirely sure what error 145 denotes in any case. Irrespective of that it is likely reproducible with any other forced corruption of an index, etc.

I'll try to create a 4.1.20 test instance and see if I can reproduce it more reliably for you.

Thanks,

Tabor
[11 Jul 2006 17:19] Valeriy Kravchuk
On June 5th you had written: "I'll try to create a 4.1.20 test instance and see if I can reproduce it more reliably for you." 

Did you have any chance to do it?
[11 Aug 2006 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".