On Thu, 18 Oct 2001, Kyle Hayes wrote: > 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.
Happens evenly between three machines: one running 2.2.16-22.0RS (from Redhat 7.0), the others running 2.4.3-12.2RS & 2.4.2-2 from Redhat 7.1 so I'm not convinced it's kernel-specific. We're running whatever hardware Rackspace provided us with, not sure, but I think they're all IDE and definitely all running ext2. The only thing that's common is the MySQL version apparently. re: Steve's suggestion, we don't shut the machines down, or at least the corruptions haven't co-incided with the odd reboot we've done. Nor have there been power failures we've been aware of; Rackspace are quite good at telling us about that kind of thing. A few people suggested FLUSH TABLES, but it sounds like a stop-gap, and I didn't realise converting to InnoDB was as simple as stopping, backing up, starting and issuing ALTER TABLE Blah TYPE=INNODB; so I'll probably end up doing that. Nor did I realise that the MySQL version I had on the boxes had InnoDB compiled in, so that sounds like the best solution so far. If it's good enough for Slashdot... In general though, is database corruption really such an occupational hazard to watch for? I was floored that any database might be even occasionally expected to corrupt its data, particularly one that's used so widely as MySQL, but I suppose even with someone like Redhat taking care of compilation, the random combination of kernel & database versions might cause some friction. Thanks for the help anyhow, guys, will be migrating to InnoDB ASAP and see if that sorts it out. -- Matthew > http://www.soup-kitchen.net/ > ICQ 19482073 --------------------------------------------------------------------- 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
