Re: Plagued by Error 127

2002-06-08 Thread Benjamin Pflugmann

Hi.

On Sat 2002-06-08 at 00:58:16 -0400, [EMAIL PROTECTED] wrote:
 First, thanks for your response.
 
 I don't have the error message in front of me, but it's something like:
 
 # myisamchk -r table
 Data rows: 56,402
 Attempting to fix records:   0/0 something something
 Data rows: 0
 #
 
 Next time it occurs I'll save the detailed error message.
 
 MySQL doesn't crash.. if it did, that might be better! Instead it just 
 returns 127 errors and I have to take it down, fix table, bring it back up.
 
 I'm going to change the code to do delete * from table where 1=1 instead 
 of truncate. I really hope that will solve my problem!

Just to put it straight... this won't solve the problem, but would
work-around it, given it works (what is a solution for you, being the
one having the problem :-).

As MySQL runs very stable for a lot of people, it would be interesting
to find out what makes it unstable for you. I am not sure I can help
finding the cause, as I did not have to battle with MySQL
unstabilities before, but maybe others on the list will.

But some pointers, which will help us: In your next mail, could you
provide the data mysqlbug is gathering, too? How made you sure MySQL
is not restarting? (have a look at the uptime in mysqladmin status).
Have a look in the mysql error log and see if anything resp. anything
strange is in there.

Bye,

Benjamin.


PS: Just to be sure, you are stopping the MySQL server while you are
running myisamchk, aren't you?

-- 
[EMAIL PROTECTED]

-
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




Plagued by Error 127

2002-06-07 Thread Thomas Lackner

A client of mine runs MySQL in a pretty high volume environment, and for 
the past couple months we've had a lot of trouble with corrupt tables 
(error 127). We've changed the MySQL version (presently to version 
3.23.49), FreeBSD version (presently to 4.5-STABLE), hardware (from IDE 
to SCSI) and of course the amount of data involved. We aren't using 
LinuxThreads, soft updates, async filesystems, or any other edgey 
performance options. The system was built by Rackspace so I can assume 
decent quality components, and besides the problem has followed us after 
a server change.

The error occurs almost at random. Usually once or twice a week, always 
on the same table, and not necessarily at high load times.

The table involved (so far it has only happened on one table) is 
frequently truncated, and it has an almost 1:1 ratio of selects and 
inserts.

I can always use myisamchk, but usually this ends up deleting every 
record in the table. (Luckily for us this is an okay situation based on 
our application) Running myisamchk on a scheduled basis is a bit too 
much of a hack for me to explain to my client -- and my conscience.

What can I do to diagnose and resolve this problem?
-- 
[EMAIL PROTECTED]


-
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




Re: Plagued by Error 127

2002-06-07 Thread Dan Nelson

In the last episode (Jun 07), Thomas Lackner said:
 A client of mine runs MySQL in a pretty high volume environment, and for 
 the past couple months we've had a lot of trouble with corrupt tables 
 (error 127). We've changed the MySQL version (presently to version 
 3.23.49), FreeBSD version (presently to 4.5-STABLE), hardware (from IDE 
 to SCSI) and of course the amount of data involved. We aren't using 
... 
 I can always use myisamchk, but usually this ends up deleting every 
 record in the table. (Luckily for us this is an okay situation based on 
 our application) Running myisamchk on a scheduled basis is a bit too 
 much of a hack for me to explain to my client -- and my conscience.

If myisamchk ends up deleting every record, that sounds really bad. 
Does it print any diagnostics as it runs through them, or does it run
silently and you end up with an empty table?  All I can think is maybe
the truncate table code is acting up.  Maybe try swapping in delete *
from table where 1=1, or drop table / create table?

Does mysql itself crash (and the table is corrupt on restart), or just
out of the blue start returning 127's?

-- 
Dan Nelson
[EMAIL PROTECTED]

-
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




Re: Plagued by Error 127

2002-06-07 Thread Thomas Lackner

First, thanks for your response.

I don't have the error message in front of me, but it's something like:

# myisamchk -r table
Data rows: 56,402
Attempting to fix records:   0/0 something something
Data rows: 0
#

Next time it occurs I'll save the detailed error message.

MySQL doesn't crash.. if it did, that might be better! Instead it just 
returns 127 errors and I have to take it down, fix table, bring it back up.

I'm going to change the code to do delete * from table where 1=1 instead 
of truncate. I really hope that will solve my problem!

- Tom

Dan Nelson wrote:
 In the last episode (Jun 07), Thomas Lackner said:
 
A client of mine runs MySQL in a pretty high volume environment, and for 
the past couple months we've had a lot of trouble with corrupt tables 
(error 127). We've changed the MySQL version (presently to version 
3.23.49), FreeBSD version (presently to 4.5-STABLE), hardware (from IDE 
to SCSI) and of course the amount of data involved. We aren't using 
 
 ... 
 
I can always use myisamchk, but usually this ends up deleting every 
record in the table. (Luckily for us this is an okay situation based on 
our application) Running myisamchk on a scheduled basis is a bit too 
much of a hack for me to explain to my client -- and my conscience.
 
 
 If myisamchk ends up deleting every record, that sounds really bad. 
 Does it print any diagnostics as it runs through them, or does it run
 silently and you end up with an empty table?  All I can think is maybe
 the truncate table code is acting up.  Maybe try swapping in delete *
 from table where 1=1, or drop table / create table?
 
 Does mysql itself crash (and the table is corrupt on restart), or just
 out of the blue start returning 127's?
 


-- 
[EMAIL PROTECTED]


-
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