From: mos (mos99fastmail.fm)
Date: Wed Nov 07 2007 - 09:45:11 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

At 05:22 PM 11/6/2007, you wrote:
>Hi David,
>
>Thanks for your reply. This helped greatly.
>
>Yeah, I supposed I could just randomly flip bits in the MySQL files
>and that would do the trick.
>
>The program I'm writing does first attempt to repair the tables with
>MySQL's utilities if they're MyISAM but InnoDB tables don't support
>repair and this program is actually meant to be a potential stop-gap
>solution in the event of hardware errors in a non-failover situation
>which can do really horrible things like corrupt InnoDB inodes thus
>rendering tables unusable to keep clients seeing SOMETHING (even if
>it's stale data) until the hardware can be swapped out.
>
>Speaking of which, can anyone think of a reason that InnoDB tables
>would corrupt aside from hardware problems or a bug in the storage
>engine?

David,
     Bad network cards could corrupt the data or flaky memory.

Here are a few links that deal with InnoDb corruption.

http://www.mysqlperformanceblog.com/2006/07/30/mysql-crash-recovery/
http://www.mysqlperformanceblog.com/2007/05/22/magic-innodb-recovery-self-healing/
http://www.google.ca/search?hl=en&q=innodb+corruption+causes&btnG=Search&meta=

Mike

>On Nov 6, 2007 6:04 PM, David T. Ashley <dashleygmail.com> wrote:
> > On 11/6/07, mos <mos99fastmail.fm> wrote:
> > >
> > > At 02:18 PM 11/6/2007, Richard Edward Horner wrote:
> > > >Hi,
> > > >
> > > >I'm working on a program that will run in the event that tables are
> > > >crashed or corrupt. Can anyone recommend a good method for crashing my
> > > >tables or corrupting them so I have some test cases? I'm mostly
> > > >interested in MyISAM and InnoDB table types.
> > > >
> > > >I was thinking I would just start an infinite loop with an UPDATE
> > > >statement in it and then kill -9 the mysqld process.
> > > >
> > > >Any better ideas?
> >
> >
> > Well, there are different types of corruption. Here are a few that come to
> > mind:
> >
> > a)Corruption of a MySQL file, perhaps not repairable (disk hardware
> problem,
> > OS crash, server power supply failure).
> >
> > b)Corruption in a way that is repairable by a MySQL utility (index file
> > corrupted).
> >
> > c)Application corruption (bad application doesn't handle mutual exclusion
> > correctly, has logical errors, etc.).
> >
> > Hopefully database repair utilities that come with MySQL will map (a) and
> > (b) to be indistinguishable from (c). (But I don't know that--I'm barely a
> > MySQL user.)
> >
> > The most even-handed way to do it would seem to be:
> >
> > a)Write a program that will create a random number of distributed and block
> > corruptions distributed randomly in the MySQL files. (Such a program would
> > take very little time to execute--well under half a second, I'm guessing.)
> > You might want to throw in truncations and blocks added at the end of
> files,
> > too.
> >
> > b)See how far the MySQL utilities (if there are any) followed by your
> > software will go towards repair.
> >
> > Doesn't seem like an easy thing to test.
> >
>
>
>
>--
>Richard Edward Horner
>Engineer / Composer / Electric Guitar Virtuoso
>richrichhorner.com
>http://richhorner.com - updated June 28th
>
>--
>MySQL General Mailing List
>For list archives: http://lists.mysql.com/mysql
>To unsubscribe: http://lists.mysql.com/mysql?unsub=mos99fastmail.fm

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]