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
Benjamin Pflugmann wrote:
> 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
> 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.
Linux rocks!!! http://www.dedserius.com