Justin a écrit :
>
> 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
Hi Justin,
I also had a similar index corruption problem with 3.23 on a linux
SMP server. This problem disappeared when I rebooted the server in
single processor mode.
I will try SMP again with a 2.4 kernel and glibc 2.2 but I can't yet
because RAID controller driver (DELL/PERC2) for 2.4 is not available.
Hope this helps
--
Joseph Bueno
NetClub/Trader.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