I have written a simple Nagios plugin that calls mysqlcheck (which checks for corrupted tables) and will give a warning if any are corrupt.

However none of my tables are corrupt now. So I'm not 100% sure that my plugin is working fine. I have a dev server that's not misson critical. How can I force one (or any) of the tables there to be corrupt so that I can test my nagios alert?

For the record the server is Ubuntu Dapper and the mysql is version 5.0

  • interesting....... – Sander Versluys Aug 12 '09 at 15:47
  • 3
    Assuming they're MyISAM tables I'd imagine you could just open a window. A slight breaze should be enough to cause those ACID free tables to crash, tip over and catch fire ;) – David Aug 12 '09 at 16:28

Generally you can't back up the databases by copying them from /var/lib/mysql and then copying them back because they get corrupted, you have to use mysqldump instead.

So if you go into one of the folders for the database in /var/lib/mysql, ie /var/lib/mysql/myDB/ and mess with some of the files that ought to do it :-)

So I would recommend copying one of the files, editing a little with a hex editor, and copying it back.

cat DB1.myd /dev/random > DB2.myd
  • I like this one! – Kyle Brandt Aug 12 '09 at 17:54
  • 1
    Won't that keep pulling data from /dev/random until my harddisk fills up? :P – Rory Aug 13 '09 at 8:30
  • 2
    Hey, you said corrupt, right? ;-) – Matt Simmons Aug 13 '09 at 12:22
  • Rory, Ya, but just hit Ctrl-C at some point – Kyle Brandt Aug 13 '09 at 14:04
  • Rory, Or use head /dev/urandom, to a file and then cat those – Kyle Brandt Aug 13 '09 at 14:05

You could use a fuzzing tool like zzuf to fuzz a preexisting database file, e.g.

zzuf < good.myd > fuzzed.myd

This should do it:

cat /dev/urandom > yourdb.myd
  • That will keep going till my harddisk fills up. – Rory Jan 22 '10 at 18:06

I'd suggest that a more realistic way to simulate fault would be to pull the rug out from beneath MySQL's feet while it's performing an intensive update. Issuing SIGKILL to the mysqld process should be sufficient. Chances are that when you restart MySQL the table(s) in question will be marked as crashed.

Alternatively I'd suggest applying other people's suggestions but to the .MYI indec file rather than the data file.



mysql> repair table Transactions;
^CQuery aborted by Ctrl+C
| Table                             | Op     | Msg_type | Msg_text              |
| test.Transactions | repair | error    | 137 when fixing table |
| test.Transactions | repair | status   | Operation failed      |
2 rows in set (17.84 sec)

mysql> select * from Transactions limit 1;
ERROR 144 (HY000): Table './test/Transactions' is marked as crashed and last (automatic?) repair failed

perhaps a command execution that does something like the following:

echo "aaa" > file.myd

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.