從ibdata1恢復mysql數據庫

Question

我有一個客戶端似乎已經從他們的本地機器丟失了所有的mysql數據庫。他們在Mac上，我有點不熟悉，我在Ubuntu上。數據庫文件夾中沒有.MYD或.MYI文件，只有.frm文件。我讓他們將mysql和視域文件夾（視爲我們需要的數據庫）以及ibdata1，ib_logfile0和ib_logfile1文件進行壓縮。我爲mysql創建了第二個文件夾/ var/lib/mysql2，並將文件和文件夾移動到那裏。我將新文件夾和文件加入到mysql：mysql，編輯/etc/mysql/my.cnf指向新文件夾，編輯/etc/apparmor.d/usr.sbin.mysqld，然後重新啓動apparmor和mysql。不過，我收到以下錯誤在mysql錯誤日誌：

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. 

我曾嘗試加入innodb_force_recovery = 4到my.cnf文件，產生不同的錯誤整體轉換：

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. 

和更多，如果有幫助，我可以提供。有什麼建議在這裏嘗試將不勝感激，謝謝。

-Michael

編輯：我嘗試以下步驟在這裏，但有使MySQL使用他使用的命令行程序運行的問題：

http://blog.shiraj.com/2012/10/extract-data-from-mysql-ibdata1-data-file/

Answer 1

以下爲我工作：

• 在你的my.cnf設置innodb_force_recovery = 1

• 試着讓你的mysqld重啓。如果不是，則重複步驟＃1並每次遞增 innodb_force_recovery直到成功。使用指南，幫助您瞭解每一次發生了什麼，你增加它：http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html

• 一旦mysqld正在運行，嘗試和轉儲所有的數據庫

mysqldump -u root -p --all-databases > /tmp/mysqldump-all.sql 

• 如果不成功，您必須首先在數據庫級別嘗試它

mysqldump -u root -p --databases db_name > mysqldump-db_name.sql 

• 如果沒有成功，你必須嘗試它放在桌子上水平

SELECT * FROM TABLE_NAME INTO OUTFILE「/tmp/table_name.sql 「

• 一旦其中的一個是成功的，無論是你所有的d b或所有表都已導出，請停止mysqld移動您的ib_logfile *> ib_logfile * .bak。這些通常在你的mysql數據目錄中。

• 如果在第一步中增加了innodb_force_recovery => 4，則需要將其設置爲低於4.從5.6.15開始，innodb_force_recovery設置爲4或更大將InnoDB置於只讀模式。

• 啓動mysqld服務器

• 導入導出的數據庫或表

的mysql -u根-p < /tmp/mysqldump-all.sql

• 增加你的innodb_force_recovery => 1

• 重新啓動mysqld服務器