查詢時發生錯誤'未知表引擎'InnoDB''。重新啓動mysql之後

Question

我在服務器S1（mysql版本5.1.41-3ubuntu12.7-log）上有mysql數據庫，我在服務器S2上創建了這個數據庫的主從服務器（mysql version 5.1.54-1ubuntu4-log）。
S1上的DB正在使用一個數據文件（ibdata）。在將數據庫轉儲到S2後，我將innodb_file_per_table設置爲1。這使每個表都有自己的ibd文件。現在一切都很順利。
但S2重新啓動mysql的後，我面臨着一個問題，收到此錯誤：
Error 'Unknown table engine 'InnoDB'' on query. Default database: MyDB ，當我試圖表明發動機

 
show engines; 
+------------+---------+----------------------------------------------------------------+--------------+------+------------+ 
| Engine  | Support | Comment              | Transactions | XA | Savepoints | 
+------------+---------+----------------------------------------------------------------+--------------+------+------------+ 
| MyISAM  | DEFAULT | Default engine as of MySQL 3.23 with great performance   | NO   | NO | NO   | 
| MRG_MYISAM | YES  | Collection of identical MyISAM tables       | NO   | NO | NO   | 
| BLACKHOLE | YES  | /dev/null storage engine (anything you write to it disappears) | NO   | NO | NO   | 
| CSV  | YES  | CSV storage engine            | NO   | NO | NO   | 
| MEMORY  | YES  | Hash based, stored in memory, useful for temporary tables  | NO   | NO | NO   | 
| FEDERATED | NO  | Federated MySQL storage engine         | NULL   | NULL | NULL  | 
| ARCHIVE | YES  | Archive storage engine           | NO   | NO | NO   | 
+------------+---------+----------------------------------------------------------------+--------------+------+------------+ 

InnoDB中沒有列出。
錯誤日誌中我可以看到這一點：

 
InnoDB: Database physically writes the file full: wait... 
InnoDB: Cannot initialize created log files because 
InnoDB: data files are corrupt, or new data files were 
InnoDB: created when the database was started previous 
InnoDB: time but the database was not shut down 
InnoDB: normally after that. 
111016 8:24:11 [ERROR] Plugin 'InnoDB' init function returned error. 
111016 8:24:11 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 
111016 8:24:11 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=S2-relay-bin' to avoid this problem. 

我試圖刪除ib_logfiles但這並沒有正常工作。
有人遇到這樣的問題之前？任何想法高度讚賞
謝謝

Answer 1

可以刪除InnoDB日誌文件：如果你沒有，那麼當您運行此有采空區指的是它的線。 儘管不要刪除InnoDB數據文件（ibdata1）。

之後，InnoDB將在重新啓動mysqld後嘗試恢復。

看看主要日誌文件：

120413 17:34:47 InnoDB: Initializing buffer pool, size = 64.0M 
120413 17:34:47 InnoDB: Completed initialization of buffer pool 
120413 17:34:47 InnoDB: Log file .\ib_logfile0 did not exist: new to be created 
InnoDB: Setting log file .\ib_logfile0 size to 32 MB 
InnoDB: Database physically writes the file full: wait... 
120413 17:34:48 InnoDB: Log file .\ib_logfile1 did not exist: new to be created 
InnoDB: Setting log file .\ib_logfile1 size to 32 MB 
InnoDB: Database physically writes the file full: wait... 
InnoDB: The log sequence number in ibdata files does not match 
InnoDB: the log sequence number in the ib_logfiles! 
120413 17:34:49 InnoDB: Database was not shut down normally! 
InnoDB: Starting crash recovery. 

Answer 2

你用innodb編譯mysql嗎？在你的MySQL數據目錄下名爲ib_logfile0和ib_logfile1

strings `which mysqld` | grep innodb 

Answer 3

我想的MySQL對於InnoDB的配置，如果你設置innodb_buffer_pool_size = 2G時，InnoDB將無法正常工作。

通常，如果您選擇使用InnoDB的系統表嘗試innodb_buffer_pool_size = 1G它給出了一個錯誤

"Unknown table engine 'InnoDB". 

。

Answer 4

服務器掛起和重新啓動後出現類似問題。

數據沒問題 - 錯誤信息非常具有誤導性。

停止MySQL服務，從/var/lib/mysql刪除日誌文件（ib_logfile*），然後啓動MySQL服務。 只要100％確定在刪除日誌文件時MySQL實際上處於關閉狀態。

Answer 5

我遇到了同樣的問題。 Nikl的回答幫助我在主日誌文件中找到問題。 InnoDB在啓動時無法分配所需的內存。在清理了一些其他的程序後，一切都開始正常。

日誌結果如下：

160219 9:20:23 InnoDB: Error: cannot allocate 12884918272 bytes of InnoDB: memory with malloc! Total allocated memory InnoDB: by InnoDB 49601872 bytes. Operating system errno: 12 InnoDB: Check if you should increase the swap file or InnoDB: ulimits of your operating system. InnoDB: On FreeBSD check you have compiled the OS with InnoDB: a big enough maximum process size. InnoDB: Note that in most 32-bit computers the process InnoDB: memory space is limited to 2 GB or 4 GB. InnoDB: We keep retrying the allocation for 60 seconds...