I'm having difficulties with version 3.23.32 in production.. after giving up on my own compiled version, which I compiled in the same way, on the same box, with the same flags as 3.22.32, I was getting occasional core dump/restarts.. so I reverted to the mysql.com binary from mysql.com Now, a large frequently accessed table was getting repeated error 127s .. Problem #1: I experimented with moving the format to MYISAM, but stability was worse: I got to the point where certain easy indexed based selects would unaccountably return no records, and alter table / myisamchk / and even insert into newtable select * from badtable would NOT fix it... moving the table format back to ISAM fixed this unhappy situation. Now I don't trust MYISAM! to confuse things further, myisamchk with extended repair option would produce thousands of weird and bogus looking error messages about invalid offsets and fragments, but not "fix" them. Problem #2: The official compiled binary can still core dump without providing any clue as to what table caused its death. Since to isamchk/myisamchk with extended repair mode on the entire database looking for problems takes several hours, this is really bothersome, and 3.22.32 would not show this behaviour, you could detect the table was corrupt as it returned nothing from your select... logging all selects is impractical in production for me.. the 2gig log file limit is reached in a few hours, and slows the server. Now this brings me up to date. Problem #3! read_next/read_const: Got error 127 when reading table ./database/tablename I get this on this large table very often, and less often on other tables.. SQL traffic to this table is very high - on the order of 100+ selects per second, continuously, with a few inserts a minute, and many little updates. This table is 500k rows,primary key, and 2 indexes. Filesize is 268mb. alter table typically makes the problem go away for a few hours to a day, then it returns. A more substantial isamchk makes no difference. Sort of problem #4: By the way: isamchk or alter table on a big table, in an active database is a disaster because this flushes out the OS file cache, causing an order of magnitude+ jump in average query time as all queries must now be resolved via slow physical disk seeks, reducing throughput of the SQL server to the point where the (in this case website) must be taken off line. I realize this is not a mysql problem really.. just thought I'd mention it in case anyone runs a very busy sql server. All this is an otherwise stable linux SMP box with 1gig of memory and SCSI drives.. box uptime is 116 days, so I discount any possible bus/memory/scsi problems. Anyway, I was running 3.22.32 previously and while it had problems (delayedInsert corrupted tables? large binary blobs would not always retrieve as they saved?), it was otherwise stable.. Should I go back to 3.22.something ? I have searched the lists a lot, and seen others post on this error, but never seen any explanation as to WHY indexes corrupt, just to repair them when they do.. thanks for any help. -Justin --------------------------------------------------------------------- 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
