On Thursday 18 October 2001 09:45, Bill Adams wrote:
> Matthew Bloch wrote:
> > I'm running several MySQL installation (all version 3.23.37 under Linux)
> > under what I presume are some fairly harsh conditions, and wondered what
> > circumstances cause tables to be corrupted and need fixing with
> > myisamchk. This is happening once every few days and it's becoming a
> > pain. I have a multithreaded process which is constantly opening and
> > closing connections to the database and trying to increase its
> > concurrency until the load average reaches something comfortable like 15,
> > and the network connection is saturated. I've had to throttle it back to
> > stop it opening more than 32 simultaenous DB connections but otherwise it
> > works fine. Until I start getting errors from the table handler, that
> > is, and the whole thing grinds to a halt until I fix the table manually.
> >
> > Can anybody shed some light on this? I can't believe I'm putting it
> > under more load than something like Slashdot would, and they don't
> > (appear to) have half the troubles I've had.
>
> I found yesterday (at the advice of this list) that adding an occasional
> call to "FLUSH TABLES" fixed my corruption problems. I would do that right
> before the disconnect or program exit.
What kernel are you using? Some of the 2.4 series have... odd... behavior
with regards to caching.
Are you using SCSI or IDE. We've run many tests with both and not had any
corruption problems unless we did something whacked like pull the power for
the machine while it was running the test.
What filesystem are you running?
Just running FLUSH TABLES sounds like it is only going to make the problem
less common, not fix it. Something is corrupting your indexes/data.
Is the data getting mangled or the index? If myisamchk can fix the problem,
it is likely that the index is the problem. MySQL will cache the index in
memory, but not the data. Thus, if you see data mangling problems and
possibly index problems, I would look at the kernel, disk etc. If you are
only see index problems, but the data looks OK, then the version of MySQL
might be a problem or maybe you have a bad build. MySQL builds more cleanly
than most OSS projects, but it is a big complex beastie and can build
incorrectly without obvious errors sometimes in our experience. Bad library
versions can also be a factor.
We've run tests with 1000 hits per second on a database on a cheasy IDE drive
without a problem. We've run those tests for hours at a time with no
problems. SCSI definitely works better than IDE, but the newer IDE drives
aren't that bad anymore. They still use a lot of CPU.
If your drives to write caching, that can be a problem if you have a power
drop. Most IDE drives (all?) will cache writes to allow the disk firmware to
reorder the writes to get better speed. This means that your carefully
flushed data will be written in an order _DIFFERENT_ from what you and the OS
thought it was written in. This can completely screw up filesystems and
definitely could have some "interesting" effects on your database.
Best,
Kyle
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MicroTelco Services saves money on every Fax:
- Fax to email (FREE)
- Fax to PSTN based Fax (Up to 95% Savings)
- Fax Broadcasting: Send 100s of faxes to fax machines
and email addresses in the time it takes to send just one!
===========================================================
So send a fax today and let us know what you think!
For more info. visit: www.internetfaxjack.com
===========================================================
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
