Rob Wultsch wrote:
On Sun, Apr 18, 2010 at 11:13 AM, Andrés Tello <mr.crip...@gmail.com> wrote:
What if the DBA ask for the backup?
And those recommendations can be "fixed" or they have a very high chance of
making recovery impossible?
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.
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.
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.
I agree with Rob. InnoDB failures are nearly always caused by OS-level
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
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
yourself, these are all things that have created problems for others in
the past.
--
Shawn Green
MySQL Principle Technical Support Engineer
Oracle USA, Inc.
Office: Blountville, TN
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
