From: Shawn Green
Date: April 18 2010 7:07pm
Subject: Re: How to corrupt a database please???
List-Archive: http://lists.mysql.com/mysql/221281
Message-Id: <4BCB5864.9000606@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Rob Wultsch wrote:
> On Sun, Apr 18, 2010 at 11:13 AM, Andr=E9s Tello <mr.criptos@stripped>=
 wrote:
>> What if the DBA ask for the backup?
>>
>> And those recommendations can be "fixed" or they have a very high chan=
ce of
>> making recovery impossible?
>>
>=20
> Who is the dba going to ask for a backup? Himself? The guy that puts
> backups on tape? One way or another the DBA damn well better know how
> to get a backup.
>=20
> Failing off of a server gets you on to a slave which should be sync'd
> with the master. If you restore from backup then you can run a pitr .
> In my opinion both of these options are usually superior to running
> repair table on a production server. That is if you like uptime.
>=20
> For the record innodb corruption is quite rare, at least in comparison
> to MyISAM corruption. If I get a call at 2AM and find a server having
> died  due to innodb corruption I would fail off of the server. No ifs,
> no ands, not buts. I would assume:
> 1. Possible, perhaps even probably hardware issues if there is Innodb
> corruptions.
> 2. A failover takes a set amount of time. Repairing corruptions will
> usually take longer, perhaps much much longer.
>=20

I agree with Rob. InnoDB failures are nearly always caused by OS-level=20
or HW-level failures. The worst-case scenario is to need to rebuild part =

of your data from whatever information remains in the corrupted file. It =

is much better to restore from backup or rebuild from a slave than to go =

through the pain of rebuilding a corrupted tablespace.

But, here are some ideas on ways to screw one up:

1) Put it on an NFS drive then read from it using another user's account =

while the database is trying to write to it.

2) Scan it with an antivirus program while it is online and actively=20
making changes.

3) Use a hex editor and manually zero out a page of data or index

4) Delete the active log file (or both of them)

5) Turn on two MySQL instances to the same files at the same time.

6) Delete the .frm file for a table

7) Take a backup of the tablespace, change a few things, the restore the =

tablespace but not the logs.

While I can't predict what "kind" of problem you will create for=20
yourself, these are all things that have created problems for others in=20
the past.

--=20
Shawn Green
MySQL Principle Technical Support Engineer
Oracle USA, Inc.
Office: Blountville, TN