MySQL Bugs: #6636: Frequent Corruption of MyISAM Tables

Bug #6636	Frequent Corruption of MyISAM Tables
Submitted:	15 Nov 2004 13:07	Modified:	15 Dec 2004 15:18
Reporter:	David Moore	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: MyISAM storage engine	Severity:	S2 (Serious)
Version:	4.0.18-Max	OS:	Linux (SuSE 9.1)
Assigned to:		CPU Architecture:	Any

Description:
Bug #563 was closed with comment: 

*Please* everybody, don't add comments here, chances are *very* high that the
corruption you experience has nothing to do with the originally reported bug
(which was already fixed).
So, please - report your corruption as a new bug. It will *not* be handled if
you add it here, this bug report is closed.

However having read it all I can not see where it was closed.

I am getting *exactly* the same thing; frequent corruption of large well used tables.  At the start i do -r and -o check Before starting server.  Then let server run for a few hours.  There are no reported errors in server, however stop and then run check again, and get "Key 1 - Found wrong stored record at 273480152, with up to 100 errors at a time"

As this is a slave, no error is noticed until the replication tries to access corrupted row, which then stops the slave.

this does NOT happen in 3.23.32 (which is the master) and happens on BOTH my mySQL 4.0.18 systems up to 10 times a day.

all comments in bug 563 seem to match mine exactly, however i cannot find the "continuation" of that bug.

Could you either let me know where the next thread for that bug starts, or how to resolve.

As the other users, it is random, therefore unrepeatable, however the logs required would be quite big.  I am sure that as the last thread finished in October 2003, that this has been resolved somewhere - would love to know where..

Thanks

Dave

How to repeat:
Cannot repeat

I wrote "is closed" for Bug#563 because it doesn't make a lot of sense to have generic "table corruption" bugreport, there could be different bugs that could make table to be (or appear) corrupted. That particular bug#563 was closed after Monty found and fixed a bug in MyISAM UPDATE code that could be triggered by some nontrivila condition during blob updates. It was fixed in 4.0.15, that's why it cannot be the same bug in 4.0.18. So you did correctly by opening a new bugreport, even though symptoms are similar :)

A good news: it should be relatively easy to repeat the bug. As you see it on replication slaves, there's no need to play with concurrent load and search for race conditions - all updates on the slaves are strictly serialized. You need to make a copy of your table files (frm, MYI, and MYD) before the corruption and start new binlog (FLUSH LOGS). Then, after corruption has occurred, replaying binlog on the saved copy of the table should be enough to repeat the corruption.

When we'll have a repeatable test case we could fix the bug very quickly.

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".