Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
interesting....... – Sander Versluys Aug 12 '09 at 15:47
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
up vote 1 down vote accepted

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.

share|improve this answer
cat DB1.myd /dev/random > DB2.myd
share|improve this answer
I like this one! – Kyle Brandt Aug 12 '09 at 17:54
Won't that keep pulling data from /dev/random until my harddisk fills up? :P – Rory Aug 13 '09 at 8:30
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
share|improve this answer

This should do it:

cat /dev/urandom > yourdb.myd
share|improve this answer
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.

share|improve this answer


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
share|improve this answer

perhaps a command execution that does something like the following:

echo "aaa" > file.myd
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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