recover mysql database from ibdata1

拟墨画扇 提交于 2021-02-03 05:59:46

问题


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/


回答1:


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




回答2:


This is worked for me:

  1. innodb_force_recovery => 2
  2. Login into MySQL server using HeidiSQL and dump all database
  3. Reinstall MySQL server and import all the database from dump file.


来源:https://stackoverflow.com/questions/15304708/recover-mysql-database-from-ibdata1

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!