僅使用 .frm 文件還原 MySQL 數據庫

我們的一台伺服器（執行 Ubuntu 12.04）最近在斷電期間崩潰，並且 MySQL 拒絕啟動備份。經過大量的試驗和錯誤，我決定完全重新安裝它。由於我無法啟動任何服務，因此無法進行轉儲，並且在此之前沒有備份。我只有 /var/lib/mysql 的副本。

一些數據庫在目錄中的所有表中都有 .MYD 和 .MYI 文件，所以我可以通過複製文件來很好地恢復它們。但是，其他人只有 .frm 文件和 db.opt。沒有其他文件。我試圖停止伺服器，從備份目錄複製 ibdata1 和 ib_logfile1 和 2 並再次啟動它，但這總是讓它再次崩潰，直到我用新文件覆蓋它們。

值得注意的是：

• 數據庫都顯示為show databases
• 表都顯示為show tables，但它們未在 information_schema.TABLES 中列出。

表格中有一些重要數據沒有被辨識，我現在真的很茫然。有沒有辦法恢復它們？

**編輯：**錯誤日誌說：

InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 5. 
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.5/en/forcing-innodb-recovery.html 
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page. 150921 12:17:58  
InnoDB: Assertion failure in thread 3064645376 in file buf0buf.c line 3623
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery. 10:17:58 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed,  something is definitely wrong and this may fail.
key_buffer_size=16777216 
read_buffer_size=131072 
max_used_connections=0 
max_threads=151 
thread_count=0
connection_count=0
It is possible that mysqld could use up to  key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346076 K  bytes of memory Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... 
stack_bottom = 0 
thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb72c90a3] 
/usr/sbin/mysqld(handle_fatal_signal+0x484)[0xb7174ce4] [0xb6e26404] 
/usr/sbin/mysqld(+0x58b708)[0xb73d4708] /usr/sbin/mysqld(+0x58c0e2)[0xb73d50e2] 
/usr/sbin/mysqld(+0x57baf7)[0xb73c4af7] 
/usr/sbin/mysqld(+0x54a05d)[0xb739305d]
/usr/sbin/mysqld(+0x54c619)[0xb7395619]
/usr/sbin/mysqld(+0x537ee7)[0xb7380ee7]
/usr/sbin/mysqld(+0x4fbc42)[0xb7344c42]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4e)[0xb717750e]
/usr/sbin/mysqld(+0x1ff8e2)[0xb70488e2]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xbe3)[0xb704c393]
/usr/sbin/mysqld(+0x16739a)[0xb6fb039a]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x6d1)[0xb6fb4381]
/usr/sbin/mysqld(main+0x27)[0xb6fa9517]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb6ae14d3] 
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.

不幸的是，重新啟動作業系統並沒有解決問題，到那時 MySQL 已經無法啟動了。

再試一次，但將 ib_logfile0 重命名為 ib_logfile0_old ib_logfile1 為 ib_logfile1_old。當 mysql 伺服器重新啟動時，這些文件會自動從 ibdata 文件中創建。

嘗試 innodb_force_recovery 選項 - mysql

[mysqld]
innodb_force_recovery = 1

如果沒有解決，我建議使用恢復工具。 Twindb和Percona

引用自：https://dba.stackexchange.com/questions/116025