List:General Discussion« Previous MessageNext Message »
From:Benjamin Pflugmann Date:August 4 1999 5:34am
Subject:Re: Phantom Row
View as plain text  
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.

Thread
[Fwd: Phantom Row]Van4 Aug
  • Re: Phantom RowBenjamin Pflugmann4 Aug
  • Re: Phantom RowVan4 Aug
    • Re: Phantom RowBenjamin Pflugmann4 Aug
  • I'm a Lousy Programmer (was Re: Phantom Row)Van4 Aug