We're trying to write a monitoring process for our master so that if a
table is corrupt it will raise flags which can then trigger
operations.
We can do the basic stuff such as asserting that the port is open and
that we can ping the machine but I want to test if any
INSERT/UPDATE/DELETEs are
not using the NFS for storage.
But in the last few Months we occasionally notice some sort of running
threads accumulation and very slow queries, on tables with many
inserts/updates, as if the Server locks itself.
Sometimes we have also corrupt tables.
however we can eliminate this condition
I recently moved from Mac OS X Server 1.x (rhapsody) with MySQL 3.23.27 to
Mac OS X 10.1 (darwin) with MySQL 3.23.47. Due to an oversight the only db
backups after the move were in non-gzip'd tarballs that were ftp'd in ASCII
mode -- ugh. Lots of missing and corrupt files.
All tables are ISAM.
In the last episode (Jan 26), Harriet Wheeler said:
I recently moved from Mac OS X Server 1.x (rhapsody) with MySQL 3.23.27 to
Mac OS X 10.1 (darwin) with MySQL 3.23.47. Due to an oversight the only db
backups after the move were in non-gzip'd tarballs that were ftp'd in ASCII
mode -- ugh.
At 04:38 -0500 2001/11/16, Jennifer Slis wrote:
when I type myisamchk my server claims command not found.
Check to see that myisamchk is in your path. Or go directly to the
/usr/local/mysql/bin directory (or where ever it's installed) and type ./myisamchk
[options]
HTH
/Rob
--
Robert
I am extremely new to mySQL (and the Linux environment all together). I have
been building/maintaining a mySQL/PHP site. Today, the site began giving me
errno 145 (cannot open file) errors. I found that meant I had at least one
corrupt table, so I went into mySQL, found I had two corrupt
I had two corrupt tables and ran
REPAIR TABLE. That fixed one of the tables, but the other one kept giving
the error msg text as 69 when writing to datafile as a result of REPAIR
TABLE. So after much searching, I found a more extensive repair mechanism in
myisamchk. However, everything I have
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
Spoiler: You may be right about the bad libs...
Kyle Hayes wrote:
On Thursday 18 October 2001 12:31, Bill Adams wrote:
Hmm, 2.2 doesn't do SMP really well. However, its drawbacks are limited to
underuse of the CPUs rather than any kind of corruption or other issue. You
would get much
Bill Adams wrote:
Spoiler: You may be right about the bad libs...
[snip]
*** OMG ***
But haha I cannot believe this, I was just looking at the libraries linked by
mysqld with ldd and it is using the informix libpthread.so. Hmm, crap. *me
slaps head*
Small Update:
o If there is no call
Hello all;
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.
; Alec O'Donnell
Subject: Frequently corrupt tables
Hello all;
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
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
; Alec O'Donnell
Subject: Frequently corrupt tables
Hello all;
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
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
.
Regards,
Heikki
- Original Message -
From: Heikki Tuuri [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, October 18, 2001 12:53 PM
Subject: RE: Frequently corrupt tables
Hi!
Well, for one, I believe that Slashdot uses InnoDB tables, which tend to
handle
a little better under very
Kyle Hayes wrote:
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
On Thursday 18 October 2001 12:31, Bill Adams wrote:
Kyle Hayes wrote:
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?
O'Donnell
Subject: Frequently corrupt tables
Hello all;
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
Hello everyone.
I am running a 2.2 Debian OS with 3.23.34a-log..
I had an entire database which was 2GB installed on a 2GB partition.
Stupidly the database is not backed up and when I attempt to access the
database an error is returned when accessing certain tables
errno: 145
Saying
Michael Blood wrote:
Hello everyone.
I am running a 2.2 Debian OS with 3.23.34a-log..
I had an entire database which was 2GB installed on a 2GB partition.
Stupidly the database is not backed up and when I attempt to access the
database an error is returned when accessing certain tables
Peter Skipworth writes:
Hi all,
Has anyone experienced anything like the following ?
I have several queries which, admittedly, are quite complex and operate on
several million rows of indexed data. The tables are naturally locked
while the query occurs, which is fine, but what is *not*
Hi all,
Has anyone experienced anything like the following ?
I have several queries which, admittedly, are quite complex and operate on
several million rows of indexed data. The tables are naturally locked
while the query occurs, which is fine, but what is *not* fine is that
occasionally,
Hi all,
Has anyone experienced anything like the following ?
I have several queries which, admittedly, are quite complex and operate on
several million rows of indexed data. The tables are naturally locked
while the query occurs, which is fine, but what is *not* fine is that
occasionally,
24 matches
Mail list logo
