A hard disk failure has left me trying to restore mysql from copy of "data" folder I had dumps of "most" content but am missing some Data folder has idbdata1 / log files / folders of .frm files So, have read a lot about this and tried many things (see below) but cannot get service to start - am a windows user with mysql 5.5

1) start service with all original log files with innodb_force_recovery = 6

InnoDB: Error: log file .\ib_logfile0 is of different size 0 100663296 bytes
InnoDB: than specified in the .cnf file 0 178257920 bytes!

2) deleted log files start service with innodb_force_recovery = 6

InnoDB: Page directory corruption: infimum not pointed to
131001 19:54:14  InnoDB: Page dump in ascii and hex (16384 bytes):len 16384; hex 

3) tried to use innodb recovery instructions at http://www.chriscalender.com/?p=49 but this uses linux and wouldnt work on my windows setup - despite installing perl

am now stuck and about to call Percona - any ideas welcome???


Have found another "data" folder from 3 months back - Can get the service started with this, but get errors

Cannot find table xxx from the internal data dictionary of innodb 
though the .frm table exists etc...

for all innodb tables - am googling solutions now


All of the files generated and used by MySQL Server -- ibdata1, ib_logfile*, .frm, .ibd, etc., should be interchangeable between operating systems -- I know from experience that they interchange between Solaris and Linux, but I stay as far away from Windows as I generally can, so I can't say that for sure... but one option might be to get a working linux MySQL 5.5 setup going, and then stop it and copy all of those files over to the linux machine in place of the existing 'datadir'.

But the next appropriate step would also be highly dependent on what exactly is happening... is the server gracefully terminating, or is it crashing repeatedly? And, it will depend on what file is causing the problem. If it's a .ibd file from just one table, then renaming that file to something other than .ibd should allow MySQL to skip past that one and move on to the next.

If you weren't using innodb_file_per_table then all of your eggs are in one very potentially delicate basket, ibdata1.

If you had binary logging enabled and only a slightly stale backup, there's also the possibility of restoring the backup on a different machine and the playing the binlogs forward to recover additional data.

Depending on your general level of system administration expertise, lack of availability of backups, and the urgency and value of the data, calling Percona or SkySQL might be the best plan.

  • good comments - thankyou, ps eggs are in ONE basket ;(( – zima10101 Oct 2 '13 at 15:08

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.