[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mysql
Subject:    I'm a Lousy Programmer (was Re: Phantom Row)
From:       Van <vanboers () server ! dedserius ! com>
Date:       1999-08-04 5:56:58
[Download RAW message or body]

Thanks to Benjamin for some obvious suggestions I was just too tired to
pay attention to and notice.  # 1, not shutdown-ing the mysqld before
the isamchk.  I guess I thought this was a little much since I'm the
only user to this dbase, and figured a flush-tables would suffice.

I believe the culprit here is in my insert in the php3 application. 
I'll have to deal with this later.  For now, I have a bunch of checks to
write.  >:(

Van out.

Benjamin Pflugmann wrote:
> 
> Hi.
> 
> On Wed, Aug 04, 1999 at 12:59:49AM -0400, you wrote
> [...]
> > > Now about the corrupted table:
> > >
> > > You did not mention how you replicated the database on the second
> > > server, by copying the binary files or by dumping and inserting SQL
> > > statements? If you copied the binary data and something was corrupt,
> > > the replicated database will also be corrupt, of course.
> > mysqldump -u -p -hotherhost dbase | \
> > mysql -u -p dbase
> 
> Well, this is just as I suggested further below, so it should have
> created a fresh new table, where there is no relation to the
> (eventually) corrupted one. I suggest, you forget about that idea with
> the spreadsheet import/export, that will not help any more than a
> dump. :-(
> 
> > Thanks, mucho Benjamin.  You've given me a little perspective.  I'm
> > getting data in there and getting it to stay, but, I have to do a
> > mysqladmin refresh after every insert.  Not good.  There's something
> > wrong in there.
> 
> Another thing just hit me: You are not running isamchk while mysqld is
> running, are you? If this is the case, you will quite sure run into
> problems:
> 
> If --skip-locking is enabled (which is the default on some systems,
> e.g. Linux), isamchk cannot tell mysqld that it is working on the
> tables, therefore mysqld will do everything like it wants just while
> isamchk is running, which will confuse both mysqld and isamchk and you
> might get improper messages and warning and in the worst case, even
> corrupted files (if one of both writes anything).
> 
> With isamchk -R1,R2 you *have* to take mysqld down or do flush tables
> before (and better is to call it afterwards, too) you run isamchk,
> since it will change the tables and you have to inform mysqld about
> the change.
> 
> The manual says the following about this matter:
> ------------------------------------------------------------
> 13 Using isamchk for table maintenance and crash recovery
> 
> [...]
> If you run mysqld with --skip-locking (with is default on some
> systems, like Linux), you can't reliably use isamchk to check a table
> when the mysqld is using the same table. If you can be sure that no
> one is accessing the tables through mysqld while you run isamchk, you
> only have to do mysqladmin flush-tables before you start checking the
> tables. If you can't guarantee the above, then you have to take down
> mysqld while you check the tables. If you run isamchk while mysqld is
> updating the tables, you may get a warning that a table is corrupt
> even if it isn't.
> 
> If you are not using --skip-locking, you can use isamchk to check
> tables at any time. While you do this, all clients that try to update
> the table will wait until isamchk is ready before continuing.
> 
> If you use isamchk to repair/optimize tables, you MUST always ensure
> that the mysqld server is not using the table (this also applies if
> you are using --skip-locking). If you don't take down mysqld you
> should at least do a mysqladmin flush-tables before you run isamchk.
> ------------------------------------------------------------
> 
> Bye,
> 
>         Benjamin.
> 

-- 
=========================================================================
Linux rocks!!!   http://www.dedserius.com
=========================================================================

---------------------------------------------------------------------
Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before
posting. To request this thread, e-mail mysql-thread9293@lists.mysql.com

To unsubscribe, send a message to the address shown in the
List-Unsubscribe header of this message. If you cannot see it,
e-mail mysql-unsubscribe@lists.mysql.com instead.

[prev in list] [next in list] [prev in thread] [next in thread]