First, thanks for your response.
I don't have the error message in front of me, but it's something like:
# myisamchk -r table
Data rows: 56,402
Attempting to fix records: 0/0 something something
Data rows: 0
#
Next time it occurs I'll save the detailed error message.
MySQL doesn't crash.. if it did, that might be better! Instead it just
returns 127 errors and I have to take it down, fix table, bring it back up.
I'm going to change the code to do delete * from table where 1=1 instead
of truncate. I really hope that will solve my problem!
- Tom
Dan Nelson wrote:
> In the last episode (Jun 07), Thomas Lackner said:
>
>>A client of mine runs MySQL in a pretty high volume environment, and for
>>the past couple months we've had a lot of trouble with corrupt tables
>>(error 127). We've changed the MySQL version (presently to version
>>3.23.49), FreeBSD version (presently to 4.5-STABLE), hardware (from IDE
>>to SCSI) and of course the amount of data involved. We aren't using
>
> ...
>
>>I can always use "myisamchk", but usually this ends up deleting every
>>record in the table. (Luckily for us this is an okay situation based on
>>our application) Running myisamchk on a scheduled basis is a bit too
>>much of a hack for me to explain to my client -- and my conscience.
>
>
> If myisamchk ends up deleting every record, that sounds really bad.
> Does it print any diagnostics as it runs through them, or does it run
> silently and you end up with an empty table? All I can think is maybe
> the truncate table code is acting up. Maybe try swapping in "delete *
> from table where 1=1", or "drop table / create table"?
>
> Does mysql itself crash (and the table is corrupt on restart), or just
> out of the blue start returning 127's?
>
--
tlack@stripped
