Hi,
our scenario (was):
server1: 5.0.32-Debian_7etch1-log
server2: 5.0.32-Debian_7etch1-log
Hardware-wise (attention, Vmware, see below) they're equal: ~1GHz CPU at at
minimum 2GB ram.
Suddenly about 4 to 6 weeks ago, server1 started getting serious problems with
spontaneous corrupted tables, so that in the end our hoster upgrade server1
to 5.0.51-2-log what we're currently running.
Unfortunately, things haven't changed a bit. server2 is running different
databases/applications, some tables are replicated from server1 to server2,
some from server2 to server1. However, server2, as far as I can remember,
never had those spontaneous table problems and still hasn't (yet).
Both servers are running on VMware (I think ESX is the product our Hoster is
using) and the MySQL data files are on a NFS exported share. Those
share/fileserver is reported to be some kind of Ueber-Beast-Killer-Maschine.
All servers running in Vmware don't contain virtual Vmware hard discs but have
NFS mounted root and data, etc. partitions.
We're very often, daily!, getting spontaneous corrupted tables on the server
with the version which gets us really in trouble.
The only pattern so far:
1) it only affects MyISAM tables
2) once converted to InnoDB, no troubles (so far)
Unfortunately there are tables we weren't able to convert because they contain
an fulltext index. Interestingly, once we converted all (except mentioned)
tables in a database, the remaining MyISAM tables won't crash anymore (so far).
Besides this, there's no distinct pattern, because we get crashes
* on high and low traffic tables
* on intensive and non-intensive write tables
* on big (range between 100 and 150MB) and small tables
It often occurred that a simple "REPAIR table" statement didn't always helped.
Sometimes "EXTENDED" was required, sometimes an offline repair with the
myisamchk had to be done.
The tables didn't crash because the whole MySQL server went down, this was
while the server was running.
We've been running the applications using the databases for years. The were
two major changes during the last year:
* our moved the MySQL server from a physical machine to Vmware
* we upgraded (better, let our Hoster upgrade) from some MySQL4 version to the
mentioned versions above.
We don't use any fancy stuff, more or less simple SELECT, DELETE, UPDATE,
INSERT. No Subselects, no triggers, no stored procedures, no key constraints,
etc, no locking, no REPLACE.
Our Hoster refers to the following MySQL bugs
http://bugs.mysql.com/bug.php?id=28154
http://bugs.mysql.com/bug.php?id=33596
However specially for 33596 I don't see any related information because this
issue described there never applied.
For 28154: Unfortunately I don't remember seeing this 127 error, however if it
ever occurred, then only a long time ago. Recent errors are just corrupted
tables once we start seeing problems in our web application. Our "thread cache
size" is 128. Mentioned in #28154 is http://bugs.mysql.com/bug.php?id=29838 .
I think that's the reason why our Hoster upgraded to 5.0.51.
For what it matters, I just can't believe that MyISAM is to blame completely
at fault. If it had that problems I just couldn't believe this was in a stable
product. I'm really curious to just to fix the problems but also find out what
the cause really is.
I would be glad for any help on this matter and I'm happy to provide any
information you want.
thanks,
- Markus
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
