Restore MySQL InnoDb from *.frm files - mysql

I was working on my Mac when it crashed, the HDD got corrupted and cant be repaired unless formating, so i recovered my DB data from OS X, i got all the folder , and now im trying to restore it in a windows computer while i repair the Mac.
I have tried several post here that says tha i just have to copy all the files to the data folder in the new MySQL instalment on windows , i already tried copying the db folder with the frm files and the ind files, then i copied the ibdata1 file and restarted the service but even so it didn't work , the i read that i had to copy also the ib_logfile0 and ib_logfile1 and so i did, but then the service didnt want to run.When i restore the original log it works but i can only see the tables in mysqlworkbench but i can't make querys to them because the log says that the tables doesnt exist even that i can see them.
Im using mysql 5.6 on windows 7 and mysqlworkbench.
Currently i have the *.frm files , the *.ibd files, the ibdata1, the ib_logfiles0 and 1 , that i rescued from my os x hdd, i copied all of them to the windows mysql installment and so the mysql service wont start.
Heres the current log when i try to start the service.
FROM CARLOSDESKTOP.err:
2014-02-11 13:27:10 7108 Note Plugin 'FEDERATED' is disabled.
2014-02-11 13:27:10 3a8 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2014-02-11 13:27:10 7108 Note InnoDB: Using atomics to ref count buffer pool pages
2014-02-11 13:27:10 7108 Note InnoDB: The InnoDB memory heap is disabled
2014-02-11 13:27:10 7108 Note InnoDB: Mutexes and rw_locks use Windows interlocked functions
2014-02-11 13:27:10 7108 Note InnoDB: Compressed tables use zlib 1.2.3
2014-02-11 13:27:10 7108 Note InnoDB: Not using CPU crc32 instructions
2014-02-11 13:27:10 7108 Note InnoDB: Initializing buffer pool, size = 8.0M
2014-02-11 13:27:10 7108 Note InnoDB: Completed initialization of buffer pool
2014-02-11 13:27:10 7108 Note InnoDB: Highest supported file format is Barracuda.
2014-02-11 13:27:12 - Server start done.
2014-02-11 13:27:12 - Status check of service 'MySQL56' returned start pending
2014-02-11 13:47:27 - Status check of service 'MySQL56' returned stopped
FROM CARLOSDESKTOP.err:
2014-02-11 13:27:12 7108 Note InnoDB: The log sequence numbers 8610473 and 8610473 in ibdata files do not match the log sequence number 13883013 in the ib_logfiles!
2014-02-11 13:27:12 7108 Note InnoDB: Database was not shutdown normally!
2014-02-11 13:27:12 7108 Note InnoDB: Starting crash recovery.
2014-02-11 13:27:12 7108 Note InnoDB: Reading tablespace information from the .ibd files...
2014-02-11 13:27:13 7108 ERROR InnoDB: space header page consists of zero bytes in tablespace .\demo\record.ibd (table demo/record)
2014-02-11 13:27:13 7108 Note InnoDB: Page size:1024 Pages to analyze:64
2014-02-11 13:27:13 7108 Note InnoDB: Page size: 1024, Possible space_id count:0
2014-02-11 13:27:13 7108 Note InnoDB: Page size:2048 Pages to analyze:64
2014-02-11 13:27:13 7108 Note InnoDB: Page size: 2048, Possible space_id count:0
2014-02-11 13:27:13 7108 Note InnoDB: Page size:4096 Pages to analyze:32
2014-02-11 13:27:13 7108 Note InnoDB: Page size: 4096, Possible space_id count:0
2014-02-11 13:27:13 7108 Note InnoDB: Page size:8192 Pages to analyze:16
2014-02-11 13:27:13 7108 Note InnoDB: Page size: 8192, Possible space_id count:0
2014-02-11 13:27:13 7108 Note InnoDB: Page size:16384 Pages to analyze:8
2014-02-11 13:27:13 7108 Note InnoDB: Page size: 16384, Possible space_id count:0
InnoDB: Error: could not open single-table tablespace file .\demo\record.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
2014-02-11 13:47:28 - Status check of service 'MySQL56' returned stopped
2014-02-11 13:47:28 - Starting server...
2014-02-11 13:48:29 - Status check of service 'MySQL56' returned start pending
2014-02-11 13:48:29 - Server start done.
2014-02-11 13:48:30 - Status check of service 'MySQL56' returned start pending

To restore the database from backup (I hope the backup was taken properly) you need at least these files
ibdata1 (and ibdata2, ibdataX if they were defined)
Database Directory with *.ibd and *.frm files
If you see tables in Workbench then you copied .ibd and .frm files only. ibdata1 looks empty because this is where InnoDB keeps tables dictionary.

Process 1
Try to install mysql same version, if your crashed mysql version was 5.6 please install mysql 5.6.
brew install mysql#5.6
If following project fail try same things with mariadb. (In my case, by mariadb, I get back all database)
Before star, must stop mysql or mariadb. Use this command
brew services stop mysql or brew services stop mariadb
ibdata1 file copy from backup mysql folder and paste and replace it inside new installed mysql folder's ibdata1 (usr/local/var/mysql) or mamp/xampp mysql folder location.
ib_logfile0 and ib_logfile1 no need to replace first. If above process don't work, copy this file from backup mysql folder and replace. (In my case, i did not replace)
Now copy 1 database for test (for example : testdb) from backup mysql folder and paste it inside new installed mysql folder. In testdb must have .frm and .ibd file.
Restart mysql/mariadb (brew services start mysql) or (brew services start mariadb)
Login MySQL -> mysql -u root -p
If everything follow, mysql login successfully.
Now check database, SHOW DATABASES;
USE testdb;
SHOW TABLES;
SELECT * FROM testdbtable;
If there don't show any massage, then its successfully restore;
Process 2
If its not work, you have to install mysqlfrm (https://downloads.mysql.com/archives/utilities/)
To find database table schema. Open terminal or your command line with your backup mysql folder mysqlfrm --diagnostic /BACKUP/mysql/testdb > /RESTORE/testdb.sql
Open testdb.sql in notepad/sublime you will see all database table schema but not data just table :( anyway, follow following step carefully.
Add ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC; end of every CREATE TABLE....ENGINE=InnoDB otherwise table may not created.
Create new database "newtestdb" and run the command >> mysqldump -uroot -p --databases newtestdb > testdb.sql
It should create all database tables, Now if you check inside "newtestdb" you will see .frm and .ibd file.
Now again login mysql >> mysql -u root -p
SHOW DATABASES;
USE newtestdb;
Run this command one by one for all table, ALTER TABLE tablename DISCARD TABLESPACE; if you check newtestbd .ibd file will disapear.
Now Copy only .ibd file from backup database testdb folder and paste it in newtestdb.
Now run ALTER TABLE tablename IMPORT TABLESPACE;
Hope now you will get back your data.

Related

MAMP Pro can't start MySQL

I had to force a shutdown when my computer froze, and MAMP has been unable to start MySql since then. I have tried deleting the log files from MAMP/DB/mysql and restarting MAMP, but it hasn't worked. I also tried entering sudo killall -9 mysqld in the terminal, to no avail.
Here is the error log from MAMP:
2017-05-12 16:05:49 4691 [Note] InnoDB: The log sequence numbers 730255276 and 730255276 in ibdata files do not match the log sequence number 730624549 in the ib_logfiles!2017-05-12 16:05:49 4691 [Note] InnoDB: Database was not shutdown normally!
2017-05-12 16:05:49 4691 [Note] InnoDB: Starting crash recovery.
2017-05-12 16:05:49 4691 [Note] InnoDB: Reading tablespace information from the .ibd files...
2017-05-12 16:05:50 4691 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace mysql/slave_worker_info uses space ID: 5 at filepath: ./mysql/slave_worker_info.ibd. Cannot open tablespace wordpress#0020test#0020site/wp_term_taxonomy which uses space ID: 5 at filepath: ./wordpress#0020test#0020site/wp_term_taxonomy.ibd
2017-05-12 16:05:50 7fff7303b000 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Error: could not open single-table tablespace file ./wordpress#0020test#0020site/wp_term_taxonomy.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
170512 16:05:50 mysqld_safe mysqld from pid file /Applications/MAMP/tmp/mysql/mysql.pid ended
Any ideas?
I've just had the same problem with MAMP.
To solve the problem, i was forced to delete the file that causes the error located in "Applications/MAMP/db/mysql56/bib" and then recreate the TABLE/BASE afterwards.
I hope that would be helpful.

MySQL InnoDB problems - InnoDB registration fails

I recently attempted to upgrade a MySQL 5.1 server to 5.7. When the server wouldn't start, I discovered you have to export the data first, else do numerous upgrades (the binaries for which aren't available anymore), so I rolled back to 5.1 to do an export.
The problem is, back on 5.1, InnoDB will no longer register. In the error log i get:
InnoDB: Error: log file ./ib_logfile0 is of different size 0 50331648 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
160822 17:05:12 [ERROR] Plugin 'InnoDB' init function returned error.
160822 17:05:12 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
As a workaround I set innodb_log_file_size=50331648 in my.cnf. Another restart and:
InnoDB: No valid checkpoint found.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/error-creating-innodb.html
Reading that links it suggests to delete all files created by InnoDB: all ibdata files and all ib_logfile files. I have a 120 GB ibdata file that I most certainly do not intend to delete, so this is a non-starter. I did try renaming the logfiles though and the server still wouldn't come up.
Any pointers from here?
Edit: I also tried renaming the iblog files. That causes another error where mysql suggests setting innodb_force_recovery=6. Doing that causes these errors:
160823 12:17:32 InnoDB: Page checksum 271832187, prior-to-4.0.14-form checksum 315921779
InnoDB: stored checksum 401867329, prior-to-4.0.14-form stored checksum 401867329
InnoDB: Page lsn 96 3891045697, low 4 bytes of lsn at page end 3891045697
InnoDB: Page number (if stored to page already) 966706,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 966706.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 966707.
InnoDB: You may have to recover from a backup.
160823 12:17:32 InnoDB: Page dump in ascii and hex (16384 bytes):
I encounter the similar problem just now. I run both MySQL 5.1 and 5.7 in the same server.
With MySQL 5.1, the default innodb_log_file_size is 5m.
mysql> show variables like 'innodb_log_file_size';
+----------------------+---------+
| Variable_name | Value |
+----------------------+---------+
| innodb_log_file_size | 5242880 |
+----------------------+---------+
1 row in set (0.00 sec)
While MySQL 5.7, the default innodb_log_file_size is 48m.
mysql> show variables like 'innodb_log_file_size';
+----------------------+----------+
| Variable_name | Value |
+----------------------+----------+
| innodb_log_file_size | 50331648 |
+----------------------+----------+
1 row in set (0.01 sec)
When upgrade a MySQL 5.1 server to 5.7 and then downgrade to 5.1, the ib_logfile0/1 file was changed in a magic way. The checkpoint of log file cannot be identified. So innodb cannot execute a normal recovery using the log files. I didn't make a deep research so i can't give a detailed explanation.
Solution
Backup datafile and restart MySQL
mv ibdata1 ibdata1.bak
mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak
service mysqld restart
Modify my.cnf file, add the following line
innodb_force_recovery=6
Restore datafile and restart again
mv ibdata1.bak ibdata1
service mysqld restart
Now you will see MySQL start successfully. Ibdata1 may not work properly. You can backup your application data using mysqldump. Then remove the recovery line in my.cnf file. Remove ibdata and logfile as well. Restart MySQL and Import your backup.
A little complex, but these help me.
Faults
As the redo log file was recreated, a little piece of log cannot be redo.
Do not delete ibdata*. That is where all the data is!
By now, the log files should not matter. So, there are a couple of ways to deal with the 'error'.
Get back the old my.cnf. If that is not practical, at least set
innodb_log_file_size = 50331648
(The change to the log file is a bit tricky. Apparently 5.7 increased it to the new default of 48MB without a problem. However, 5.1 does not have the code to dynamically change the file size.)
Another approach is to delete (or move aside) the iblog* files.

mysql not working , it is not starting

here is a bit of the error log .
160422 10:45:00 [Note] InnoDB: The log sequence numbers 1665244 and 1665244 in ibdata files do not match the log sequence number 15857945 in the ib_logfiles!
160422 10:45:00 [Note] InnoDB: Database was not shutdown normally!
160422 10:45:00 [Note] InnoDB: Starting crash recovery.
160422 10:45:00 [Note] InnoDB: Reading tablespace information from the .ibd files...
160422 10:45:00 [Note] InnoDB: Restoring possible half-written data pages
160422 10:45:00 [Note] InnoDB: from the doublewrite buffer...
160422 10:45:00 [Note] InnoDB: 128 rollback segment(s) are active.
160422 10:45:00 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.22-72.0 started; log sequence number 15857945
160422 10:45:00 [Note] InnoDB: !!! innodb_force_recovery is set to 2 !!!
160422 10:45:00 [Note] Plugin 'FEEDBACK' is disabled.
160422 10:45:00 [Note] Server socket created on IP: '::'.
160422 10:45:00 [ERROR] mysqld.exe: Table '.\mysql\db' is marked as crashed and last (automatic?) repair failed
160422 10:45:00 [ERROR] Fatal error: Can't open and lock privilege tables: Table '.\mysql\db' is marked as crashed and last (automatic?) repair failed
plz somebody help , i have one important database ,whose backup i have not made , i posted this question earlier ,but didnt got the answer ...this started when i was trying to access phpmyadmin , from then on mysql is not starting.
I see two potential ways out of it.
For the following:
Table '.\mysql\db' is marked as crashed and last (automatic?) repair failed
You can use mysqlcheck to repair it, if it is a MyISAM DB. Else try the InnoDB force recovery option if it is InnoDB database. You can start your DB with InnoDB force recovery and take a DB dump from it, to restore it on a fresh MySQL install.
In future, try enabling innodb_file_per_table option.
Now, second option. Even though the first one looks most likely.
The log sequence numbers 1665244 and 1665244 in ibdata files do not match the log sequence number 15857945 in the ib_logfiles!
If the first method doesnt work, give this a try. It looks like the ib_logfiles are corrupt, I faced this issue before and used the following steps to get my DB up and working:
Take a full backup of your mysql datadir in another directory.
Make sure mysql service is stopped.
remove the ib_logfile1 and ib_logfile2
Start the MySQL service
Hope it helps
Rishav, innodb_force_recovery doesn't recover anything. It is a mode you start your mysql with. Once it starts, you should be able to take a dump. Following should be the steps:
Steps to get it back up.
1. Stop mysqld.
2. Backup /var/lib/mysql/ib*
3. Add the following line into /etc/my.cnf
innodb_force_recovery = 4
4. Restart mysqld.
5. Dump your DB using mysqldump to a dump.sql file.
6. Drop all databases which need recovery.
7. Stop mysqld.
8. Remove /var/lib/mysql/ib*
9. Comment out innodb_force_recovery in /etc/my.cnf
10. Restart mysqld. Look at mysql error log. By default it should be /var/lib/mysql/server/hostname.com.err to see how it creates new ib* files. (Although, I recommend a fresh setup here)
11. Restore databases from the dump:mysql < dump.sql

recover mysql database from ibdata1

I have a client who appears to have lost all of their mysql databases from their local machine. They are on a Mac, which I am somewhat unfamiliar with and I am on Ubuntu. There were no .MYD or .MYI files in the database folder, only .frm ones. I had them zip up the mysql and sight folders (with sight being the database we need), and the ibdata1, ib_logfile0, and ib_logfile1 files. I created a second folder for mysql, /var/lib/mysql2, and moved the files and folders into there. I chowned the new folder and files to mysql:mysql, edited /etc/mysql/my.cnf to point to the new folder, edited /etc/apparmor.d/usr.sbin.mysqld, and then restarted apparmor and mysql. However, I am getting the following errors in the mysql error log:
130308 17:38:16 [Note] Plugin 'FEDERATED' is disabled.
130308 17:38:16 InnoDB: Initializing buffer pool, size = 8.0M
130308 17:38:16 InnoDB: Completed initialization of buffer pool
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130308 17:38:16 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
130308 17:38:16 InnoDB: Error: space id and page n:o stored in the page
InnoDB: read in are 0:589824, should be 0:7!
130308 17:38:16 InnoDB: Error: page 589824 log sequence number 786432 0
InnoDB: is in the future! Current system log sequence number 0 63932940.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
InnoDB: for more information.
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
130308 17:38:16 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 0008000000090000000a0000000b0000000c00000000000000000000000202720000 (snipped because this goes on for a while)
Tg 9 <o q E i F / D ;InnoDB: End of page dump
130308 17:38:16 InnoDB: Page checksum 4146777650, prior-to-4.0.14-form checksum 1800374066
InnoDB: stored checksum 524288, prior-to-4.0.14-form stored checksum 0
InnoDB: Page lsn 786432 0, low 4 bytes of lsn at page end 0
InnoDB: Page number (if stored to page already) 589824,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
I have tried adding innodb_force_recovery = 4 to the my.cnf file, which generates a whole slew of different errors:
130308 17:48:30 [Note] Plugin 'FEDERATED' is disabled.
130308 17:48:30 InnoDB: Initializing buffer pool, size = 8.0M
130308 17:48:30 InnoDB: Completed initialization of buffer pool
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130308 17:48:30 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
130308 17:48:30 InnoDB: Error: space id and page n:o stored in the page
InnoDB: read in are 0:589824, should be 0:7!
130308 17:48:30 InnoDB: Error: page 589824 log sequence number 786432 0
InnoDB: is in the future! Current system log sequence number 0 63932940.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
InnoDB: for more information.
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
and a whole bunch more, which I can supply if it helps. Any suggestions on what to try from here would be greatly appreciated, thanks.
Edit: I tried following the steps here, but was having issues getting mysql to run using the command line sequence he used:
http://blog.shiraj.com/2012/10/extract-data-from-mysql-ibdata1-data-file/
The following worked for my:
Set innodb_force_recovery = 1 in your my.cnf
Try and get your mysqld to restart. If not, repeat step #1 and increment
innodb_force_recovery by each until successful. Use the guide to help you understand what's happening each time you increment it: http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html
Once mysqld is running, try and dump all your databases
mysqldump -u root -p --all-databases > /tmp/mysqldump-all.sql
If that isn't successful, you'll have to try it first on the database level
mysqldump -u root -p --databases db_name > mysqldump-db_name.sql
If that isn't successful, you'll have to try it on the table level
SELECT * FROM table_name INTO OUTFILE '/tmp/table_name.sql'
Once one of those is successful and either all your db's or all your tables are exported, stop the mysqld
Move your ib_logfile* > ib_logfile*.bak. These are typically in your mysql data directory.
If in the first step you incremented your innodb_force_recovery => 4, you need to set it below 4. As of 5.6.15, an innodb_force_recovery setting of 4 or greater places InnoDB in read-only mode.
Start the mysqld server
Import your exported databases or tables
mysql -u root -p < /tmp/mysqldump-all.sql
Incremented your innodb_force_recovery => 1
Restart the mysqld server
This is worked for me:
innodb_force_recovery => 2
Login into MySQL server using HeidiSQL and dump all database
Reinstall MySQL server and import all the database from dump file.

MySQL InnoDB database restore using .frm files and ibdata files

Hi mistakenly I have deleted my MySQL database from Windos XP based PC (this database was used to host a Wiki service using Xampp package). Now I am trying to restore the data so that I can atleast retrieve the TEXT entered in the respective table of Mediawiki package.
After deletion I tried to recover the data using Minitool data recovery software and was able to recover the main schema folder containing .frm files, ib_logfile0, ib_logfile1 and ibdata1 (which was stored under C>xampp>mysql>data).
Now I am trying to restore the database so that I can take a SQL dump and use it accordingly. I have consulted some previous suggestions provided by the experts. Below are the links -
Restoring MySQL InnoDB files on Windows
Stackoverflow answers
But these did not help me very much, not sure what exactly I am missing from the instructions. At the end I was unable to start MySQL service and it failed with the below errors in log -
120823 12:17:04 [Note] Plugin 'FEDERATED' is disabled.
120823 12:17:04 InnoDB: The InnoDB memory heap is disabled
120823 12:17:04 InnoDB: Mutexes and rw_locks use Windows interlocked functions
120823 12:17:04 InnoDB: Compressed tables use zlib 1.2.3
120823 12:17:04 InnoDB: Initializing buffer pool, size = 16.0M
120823 12:17:04 InnoDB: Completed initialization of buffer pool
120823 12:17:04 InnoDB: highest supported file format is Barracuda.
InnoDB: No valid checkpoint found.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/error-creating-innodb.html
120823 12:17:04 [ERROR] Plugin 'InnoDB' init function returned error.
120823 12:17:04 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120823 12:17:04 [ERROR] Unknown/unsupported storage engine: InnoDB
120823 12:17:04 [ERROR] Aborting
Any help to recover from this situation will be highly appreciated. I am willing to provide some more data if required. [MySQL Server Version 5.5, xampp-win32-1.8.0-VC9]
Oh God finally it's solved :)
Actually I am a novice that's why I could not solve this quickly. Here is the workflow I followed.
I installed a fresh copy of MySQL server. Run Wizard config for transactional database.
I stopped MySQL from Services.msc
Then overwrote the ib* and *frm files (under the schema folder) in C/programdata/mysql/mysql server 5.5/data folder
Updated the my.ini in C/apps/mysql with the innodb_log_file_size=<actual size of iblogfile0>
ran the command mysqld --defaults-file="C:/apps/mysql/my.ini" --standalone --console --innodb_force_recovery=6
once the above completed closed cmd.exe
restarted MySQL service
Opened MySQL workbench and took a dump
Sorry to confuse you all. Thanks again. Let me know if anybody requires any clarity for the above steps.