MySQL Forums
Forum List  »  Data Recovery

Add table from tape backup to database recovered from dump
Posted by: Mark Price
Date: May 03, 2008 09:28PM

I hosed my wiki! I was trying to change the number of characters you can search in in Mediawiki. I made the change to my.cnf and then did the advised reindex, after which my wiki database was totally whacked. And of course, I hadn't done a backup immediately before.

The network guys had all the databases files on tape from the day before. They dumped them into a temp directory for me. In the course of my panicked flailing In unstalled/reinstalled MySQL 5.0 (not sure why--like I said, I was panicked) and got that running again.

I tried just copying restored FRM, MYI, MYD files into new wikidb data directory and restarting MySQL service, but all MySQL can see from the MySQL Tools Administrator is the hit counter table.

The I found a sql file from a dump I'd done a couple weeks ago. I created a new wikidb database and imported from the dump. Much better. All but two tables were created. I can see the data in them. Mediawiki can connect to the database but stalls out over the two missing tables.

I copied the two missing tables' FRM files from the file restored into the wikidb folder and restarted the service, but MySQL can't see them. I did a REPAIR TABLE USE_FRM and got the table name to show up in the MySQL Tools Administrator and in the Query Browser, but when I try to open the table in Query Browser, I get the message "Can't fetch columns."

Is there a way to bring these to tables in from FRM files, or for that matter, to bring the whole database in from these files restored from tape backup? The tables are Innodb. We're on MySQL 5.0 on Windows 2003 Server. Thanks!

Options: ReplyQuote

Written By
Add table from tape backup to database recovered from dump
May 03, 2008 09:28PM

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.