Re: Corrupting MySQL on purpose for testing
Try putting the data directory on a small partition and let it get filled 100% with a single update that does not get fully committed due to disk full, then turn the power off to the computer so there is no attempt for a nice shutdown. You should also get a corruption in the master binary logs, if binary logging is turned on. If you use VMWare (vmware server is free) to virtualize a test OS with small drives, it will be easier to do this. -RG 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? > > Thanks, Rich(ard) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Corrupting MySQL on purpose for testing
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 <[EMAIL PROTECTED]> wrote: > On 11/6/07, mos <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://richhorner.com - updated June 28th -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Corrupting MySQL on purpose for testing
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? Thanks, Rich(ard) On Nov 6, 2007 6:04 PM, David T. Ashley <[EMAIL PROTECTED]> wrote: > On 11/6/07, mos <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://richhorner.com - updated June 28th -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Corrupting MySQL on purpose for testing
On 11/6/07, mos <[EMAIL PROTECTED]> 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.
Re: Corrupting MySQL on purpose for testing
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? Sure, power off the computer or throw the breakers when doing updates to simulate a power failure. That's sure to work. :) Mike -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Corrupting MySQL on purpose for testing
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? Thanks, Rich(ard) -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso [EMAIL PROTECTED] http://richhorner.com - updated June 28th -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
