2

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

  • 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 – akuzminsky Jul 17 '15 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 – FabioG Jul 20 '15 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. – Mircea Vutcovici Jul 25 '15 at 2:14
  • Time to finally think about getting a budget for a working backup! – Marc Stürmer Jul 25 '15 at 17:49
  • are fix your problem? – Karthi Dec 16 '16 at 10:58
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.