> This is a problem that's been giving me headaches a lot recently, and may be
> related to some problems I've been having with MySQL for a couple years.
> Basically, I'm running various versions of MySQL (the problem seems
> version-independant -- currently 3.22.25) on a dual-proc i686 system, 512 meg
> RAM, and RedHat 5.2 with all the current updates. Originally I was running
> copies of MySQL that I'd built, but I recently installed a precompiled copy in
> hope that it might help the problem, but it hasn't.
> The server has about eight databases on it, ranging from being largely empty to
> the largest having about 150 meg of data in it. The problem seems to start with
> the latter database, but once it gets going, it'll plow through completely
> unrelated data.
> The problem in a nutshell is I'm getting nearly constant table corruption. Often
> the corruption actually cases isamchk to coredump or other wierd problems. Usually
> I can convince isamchk to actually run and fix the problems (which range from
> duplicate keys, to records pointing beyond the end of the datafile, and others)
> but I always lose large amounts of data in the process, although isamchk doesn't
> indicate I'm losing data (should it?). If I drop the table, recreate it, and
> reinsert the data, it'll sometimes build the entire table cleanly, but a day or
> two later -- not necessarily after any inserts or updates -- it'll be corrupted
> again. Usually a query against the table that hits one of the bad data rows will
> cause mysqld to blow core, and for whatever reason safe_mysqld can't restart it,
> usually necessatating killing the server by hand and restarting safe_mysqld.
> The table in question is a simple one, an integer, a 32-byte char field, a count
> field and a category field, everything int(10) except for the word field.
> Its used as a lookup for a text search engine, pages identified by one of the
> integers have a count for a given word stored in there. Simple really, the table
> is usually in the 1.2 million record range.
> I can tell when the corruption has happened because mysqld starts crapping out.
> When I check all the tables, I'll always see errors in that table, and often in
> other tables that have been having *selects* happening (not just updates or
> insertions, most tables never change) and the corruption usually crosses the
> database boundaries, to other databases.
> As I said before, isamchk will usually eventually fix the table, but I always
> lose data, and sometimes it actually corrupts things further in the process. (ie,
> I run it once, it says its done, I run it again, it finds a few more errors,
> and eventually its done and the table is short those 1.2 million records!)
> Has anyone ever had problems like this before? I know Slashdot was having and
> occasionally still has a lot of trouble with MySQL -- does it just simply not
> scale? Does high loads lead to this problem? With the exception of MySQL, the
> system its on is 100% rock solid. Before I added another 256meg to it last week,
> it was on 190 days uptime... so its not likely hardware related.
> Any help is appreciated. I'm hoping I can fix this without having to replace MySQL
> with a more robust database like Sybase or something.
> - George Hartz
Seem you are running isamchk while mysqld is also up (perhaps in a cron job).
Be sure to shutdown mysqld before running isamchk on the tables!