MySQL Forums
Forum List  »  Data Recovery

Backup and Restore Situation
Posted by: RE C
Date: October 27, 2009 09:02AM

I have a situation where I am attempting to restore a database that had a misguided query go awry.

I have a backup of the table in question. I restored this to another server.

We copied the missing data (between date of back up and date of corruption) with corruption to the new server/table.

We applied queries to correct the corrupt data.

We added the new data that has been added each day.

Now what I am looking to do is restore the new table to replace the corrupted one on the servers, yes servers. I have a master with 2 slaves. Locally a master and slave and a remote slave on replication.

My plan to this point was once the table on the new server (not part of the master/slaves) is created. We bring down all the servers. Export out the table from the new table via mysqldump.

Take and import that into the local master via mysql < dumpfile.

This should replace the table on the local master.

The questions....

1) Will replication copy the new table over to the slaves, yeah it probably will be a resource hog for a while, but this will be off hours.

2) Is there a better way? One other way I have considered is to just copy off the table files in /var/lib/mysql/DB/

table.frm table.MYD table.M

Then copy these into the directory on the server(s).

Or should I

3) import the new table exported to each server directly to restore that table?

Any implications on replication?

All servers would be down, then bring the master up, local slave, then remote slave... but I don't want it to corrupt up the restored table. There will be no activity in any table during the down/restoration time.

Comments, guidance, better method(s), plan....


Options: ReplyQuote

Written By
Backup and Restore Situation
October 27, 2009 09:02AM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.