Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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/

like image 260
Michael VanDeMar Avatar asked Mar 08 '13 22:03

Michael VanDeMar


People also ask

How do I recover MySQL database?

In Database Explorer, right-click the server connection on which you want to restore the database and select Backup and Restore > Restore Database. In the Database Restore Wizard, select the backup file and click Restore.

What is the use of ibdata1 file in MySQL?

The file ibdata1 is the system tablespace for the InnoDB infrastructure. You can separate Data and Index Pages from ibdata1 by enabling innodb_file_per_table . This will cause any newly created InnoDB table to store data and index pages in an external .

Can I delete ibdata1 file in MySQL?

The ibdata1 file can be shrinked if you delete all databases, remove the files and reload the mysqldump. We can configure MySQL so that each table, including its indexes, is stored as a separate file. It is enabled by default as of version 5.6. 6 of MySQL.


1 Answers

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

like image 172
zmonteca Avatar answered Sep 19 '22 10:09

zmonteca