Bug #20232 MERGE table corruption error message should indicate which member is corrupted
Submitted: 2 Jun 2006 15:51 Modified: 5 Jul 2006 22:05
Reporter: [ name withheld ] Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Merge storage engine Severity:S4 (Feature request)
Version:4.1.18 OS:Linux (RedHat 9)
Assigned to: CPU Architecture:Any
Triage: Triaged: D5 (Feature request)

[2 Jun 2006 15:51] [ name withheld ]
Description:
I have very large merge table with 380 million rows across 33 member tables. One of those tables ended up corrupt after a server crash.

The result is that when trying to access the merge table an error of the form:

ERROR 1016 (HY000): Can't open file: 'merge_mailsent.MRG' (errno: 145)

is displayed and:

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

is logged to the server error log.

The problem is that this provides no information on which of the member tables is corrupt and an exhaustive set of CHECK TABLE statement is required to identify the corrupted member table.

Since the server obviously knows which member of the merge is the corrupted one, please include it in the log output in this case.

How to repeat:
1) Create a merge table.
2) Corrupt the index of one member of the merge such that errno: 145 is generated
3) from a mysql> shell run DESCRIBE on that merge table

Suggested fix:
See description. Include corrupted member table name in error output and log file.
[3 Jun 2006 13:30] Valeriy Kravchuk
Thank you for a reasonable feature request.
[5 Jul 2006 22:05] [ name withheld ]
Is it possible that this can be changed from a feature request to a bug and be assigned? That the server doesn't provide adequate information to troubleshoot in this case seems a fair reason to be classified as a bug rather than a feature request.

This is a huge time waste for your users using large merge tables. We had a similar instance today on a different merge table of ours and we spent almost 3 hours trying to determine which of the dozens of member tables in our merge was the one creating the problem.

Being able to dramatically reduce the time to recover when a member table of a merge fails would be a significant improvement for your merge table users.

Thanks,

Tabor