3

Our server crashed last week and we lost a lot of information. We were able to recover .frm files for the tables, ib_logfile0, ib_logfile1 and ibdata1 but no .ibd.

I've tried the innodb-force-recovery on all levels 1 to 6 and a whole lot of other 'solutions' I've found online, without any success.

Right now I was trying to do it trhough a mysqldump and restore of the database but run into the same problem Mathew over here.

this answer looks like it might work. My problem is, first - my server is Windows based, second - I lack the knowledge and skills to apply this on windows command line.

By any chance is there a similar solution for Windows

edit

we were not using innodb_file_per_table so all data should be stored on ibdata1

Improve this question
4
  • The inconsistent InnoDB dictionary yields "table doesn't exist" error. But there is another problem. A table's data are in a corresponding .ibd file. It makes no sense to try mysqldump. I would take an image from the disk and fetched table records. See twindb.com/take-image-from-corrupted-hard-drive and twindb.com/recover-corrupt-mysql-database for some ideas Commented Jul 17, 2015 at 17:44
  • 1
    I've been talking to my colleagues this morning and they say we never had .ibd files because of not using innodb_file_per_table all data should be stored on ibdata1 Commented Jul 20, 2015 at 8:40
  • If you have backups, you should restore from them. If you have a disk corruption and no backups, first step is to image the disk using something like ddrecue. Then make copies of the image and try to fix the problem on those copies. Commented Jul 25, 2015 at 2:14
  • Time to finally think about getting a budget for a working backup! Commented Jul 25, 2015 at 17:49

1 Answer 1

Reset to default
0

This MySQL forum post looks like a success story, although a bit old. I remember a similar story of mine, on Linux. Windows platform doesn't matter here, MySQL data files structure is similar. No command line work is really needed. I assume your Ibdata file is not damaged in any way.

AFAIK you don't need ib_logfile? files at all, the forum post confirms that. The key operations here are:

  1. a new installation of MySQL (use the same version);
  2. manual recreation of identically-named databases, can be done from the latest backup dump if you have one;
  3. disabling innodb_file_per_table in my.cnf, it's best to restore the old config;
  4. replacing Ibdata in new installation with the recovered one.

After you start MySQL you should be able to browse and dump your data from InnoDB tables.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.