没有innodb。Unknown table engine 'InnoDB'

execute failed: Unknown table engine 'InnoDB'

我用的是linux版的xampp。本来是好的，不过由于今天突然断电，机子重启后，在mysql中执行select语句就遇到这个错误，show engines，发觉只有7条记录，缺少了InnoDB这条记录。再show variables like "have_%",看到have_innodb的value是no。再看my.cnf，skip-innodb那行是注释掉的，文件设置也是对的。

请问这种情况，我是不是只能重装xampp了，有没有什么办法不用重装这个软件？

谢谢。

25 个解决方案

#1

检查MYSQL的错误日志。

#2

1. 看看错误日志
2. 看看my.cnf中有什么实质的相关内容

#3

估计是ib_logfile文件坏了如果没备份要悲剧了

#4

请问linux版xampp的mysql的错误日志在哪啊？我怎么找不到。

#5

MySQL 5.1参考手册

5.11. MySQL日志文件
5.11.1. 错误日志
5.11.2. 通用查询日志
5.11.3. 二进制日志
5.11.4. 慢速查询日志
5.11.5. 日志文件维护
MySQL有几个不同的日志文件，可以帮助你找出mysqld内部发生的事情：

日志文件
记入文件中的信息类型

错误日志
记录启动、运行或停止mysqld时出现的问题。

查询日志
记录建立的客户端连接和执行的语句。

更新日志
记录更改数据的语句。不赞成使用该日志。

二进制日志
记录所有更改数据的语句。还用于复制。

慢日志
记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询。

默认情况下，所有日志创建于mysqld数据目录中。通过刷新日志，你可以强制 mysqld来关闭和重新打开日志文件（或者在某些情况下切换到一个新的日志）。当你执行一个FLUSH LOGS语句或执行mysqladmin flush-logs或mysqladmin refresh时，出现日志刷新。参见13.5.5.2节，“FLUSH语法”。

如果你正使用MySQL复制功能，从复制服务器将维护更多日志文件，被称为接替日志。相关讨论参见第6章：MySQL中的复制。

5.11.1. 错误日志
错误日志文件包含了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。

如果mysqld莫名其妙地死掉并且mysqld_safe需要重新启动它，mysqld_safe在错误日志中写入一条restarted mysqld消息。如果mysqld注意到需要自动检查或着修复一个表，则错误日志中写入一条消息。

在一些操作系统中，如果mysqld死掉，错误日志包含堆栈跟踪信息。跟踪信息可以用来确定mysqld死掉的地方。参见E.1.4节，“使用堆栈跟踪”。

可以用--log-error[=file_name]选项来指定mysqld保存错误日志文件的位置。如果没有给定file_name值，mysqld使用错误日志名host_name.err 并在数据目录中写入日志文件。如果你执行FLUSH LOGS，错误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项，则不会重新命名）。

如果不指定--log-error，或者(在Windows中)如果你使用--console选项，错误被写入标准错误输出stderr。通常标准输出为你的终端。

在Windows中，如果未给出--console选项，错误输出总是写入.err文件。

5.11.2. 通用查询日志
如果你想要知道mysqld内部发生了什么，你应该用--log[=file_name]或-l [file_name]选项启动它。如果没有给定file_name的值，默认名是host_name.log。所有连接和语句被记录到日志文件。当你怀疑在客户端发生了错误并想确切地知道该客户端发送给mysqld的语句时，该日志可能非常有用。
mysqld按照它接收的顺序记录语句到查询日志。这可能与执行的顺序不同。这与更新日志和二进制日志不同，它们在查询执行后，但是任何一个锁释放之前记录日志。(查询日志还包含所有语句，而二进制日志不包含只查询数据的语句）。

服务器重新启动和日志刷新不会产生新的一般查询日志文件(尽管刷新关闭并重新打开一般查询日志文件)。在Unix中，你可以通过下面的命令重新命名文件并创建一个新文件：

shell> mv hostname.log hostname-old.log
shell> mysqladmin flush-logs
shell> cp hostname-old.log to-backup-directory
shell> rm hostname-old.log
在Windows中，服务器打开日志文件期间你不能重新命名日志文件。你必须先停止服务器然后重新命名日志文件。然后，重启服务器来创建新的日志文件。

5.11.3. 二进制日志
二进制日志以一种更有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息。

二进制日志包含了所有更新了数据或者已经潜在

#6

啊，非常谢谢。找到了mysql的错误日志。我重启后，错误日至说明如下：

101210 13:17:21 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: Unable to lock /opt/lampp/var/mysql/ibdata1,error:11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
101210 13:17:21 InnoDB: Retrying to lock the first data file
InnoDB: Unable to lock /opt/lampp/var/mysql/ibdata1,error:11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
.....

#7

哦，解决了，删掉ibdata1、ib_logfile0、ib_logfile1就好了。

可又出新问题了，我在数据库里，show tables，看到这个那些表，可就是执行select，不让我访问，说这个表不存在。。。。。不会数据库坏了吧？

#8

你把IBDATA1都给删除了，INNODB的数据就全没有了。自然这些表就不存在了。

INNODB和MYISAM存储引擎不一样，它的数据是放在IBDATA中的。

#9

删到是没删，我只是改了个名。我还是可以再改回去的。可是我不把ibdata1删掉，它就会报InnoDB: Unable to lock /opt/lampp/var/mysql/ibdata1,error:11

那我那些表还是访问不了啊。

#10

做好备份。

然后在MY。INI文件中添加参数 innodb_force_recovery=1
试试，不行就加大这个数字，最大可以加到6.

提醒：做好备份。

#11

那我还要把ibdata1还原成原先那个吗？

这个备份是做哪个备份？数据库表？还是mysql的系统文件啊？

#12

那就备份整个目录，全备了。

#13

我加了那个参数，现在加到2，还是说Table 'XXX.XXX' doesn't exist

我看了下mysql的错误日志，也还是说
cannot find or open table XXX/XXX from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe ......

改这个数字是不是没有用阿？

我如果把ibdata1恢复成以前的那个文件，innodb又启不起来。。。。

#14

把ibdata1恢复成以前的那个文件
然后逐步加这个innodb_force_recovery=1

#15

用以前的还是不行，我把值改到4，报的错都是一样的。

InnoDB: Unable to lock /opt/lampp/var/mysql/ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
101210 15:17:41 InnoDB: Unable to open the first data file
InnoDB: Error in opening /opt/lampp/var/mysql/ibdata1
101210 15:17:41 InnoDB: Operating system error number 11 in a file operation.
InnoDB: Error number 11 means 'Resource temporarily unavailable'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.htmlInnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!
101210 15:17:41 [ERROR] Plugin 'InnoDB' init function returned error.
101210 15:17:41 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.101210 15:17:41 [Note] PrimeBase XT (PBXT) Engine 1.0.08 RC loaded...

#16

那这样我就有点不明白了，我把ibdata1、ib_logfile0、ib_logfile1这三个文件删了，重启mysql，系统会重新生成这三个文件，既然原innodb数据没了，这不就等于我重新安装了一个mysql吗？那我要移一个innodb数据库近来，要怎么弄呢？xampp下的mysql,每个数据库就是一个文件夹，里面有.frm .myd .myi这三种文件。

#17

InnoDB: Unable to lock /opt/lampp/var/mysql/ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process

你是不是已经有一个MYSQLD进程启动了？

#18

没有啊。我每次都stop mysql的，而且我也查了。会不会是ibdata1这个文件损坏了啊？

#19

我用以前的ibdata1，在mysql里直接show engines，都没有innodb的纪录，have_innodb值都是no

#20

引用

没有啊。我每次都stop mysql的，而且我也查了。会不会是ibdata1这个文件损坏了啊？

应该是文件有问题。一般应该试着用 innodb_force_recovery=1试着恢复一下。但显然不是100%都能恢复。

恢复的时候，你需要原来的三个文件 ibdata1, ib_logfile0、ib_logfile1

#21

引用 20 楼 acmain_chm 的回复:

引用没有啊。我每次都stop mysql的，而且我也查了。会不会是ibdata1这个文件损坏了啊？应该是文件有问题。一般应该试着用 innodb_force_recovery=1试着恢复一下。但显然不是100%都能恢复。

恢复的时候，你需要原来的三个文件 ibdata1, ib_logfile0、ib_logfile1

那文件有问题了，是不是就没戏啦？

那三个文件我也一直没删，只是改了个名。你刚才说了以后，我就改回来，然后改innodb_force_recovery的参数，从1改到4，都报一样的错
InnoDB: Unable to lock /opt/lampp/var/mysql/ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
而且mysql启动相当的慢。启动好后，我在mysql环境下对那个innodb数据库进行操作，都说unknown table engine 'InnoDB'。执行show engines，都没有innodb的纪录，have_innodb的值都是no。

我想既然innodb引擎都找不到，那貌似该什么值都没用了。我在网上看到有说把这三个文件删掉，innodb引擎就可以起来了，然后我就把这三个文件移走了，重启mysql，innodb的问题解决了，但现在不认数据库里的table了。

其实我这个数据库是bugzilla的数据库，数据库的建立是安装bugzilla时软件自动建的。我有用mysqldump备份数据库，是 .sql文件,我是不是source一下就可以啦？还是对于innodb型数据库，导入sql文件有别的说法啊？

我现在都不敢动了。。。。

#22

谢谢，搞定了，用了以前的ibdata1的备份文件，改宿主名为nobody:nobody，删掉ib_logfile0和1这两个文件。重启mysql，就ok了。不过这几天的记录都没了。

#23

引用 22 楼 nocturne1210 的回复:

谢谢，搞定了，用了以前的ibdata1的备份文件，改宿主名为nobody:nobody，删掉ib_logfile0和1这两个文件。重启mysql，就ok了。不过这几天的记录都没了。

我也碰到这问题了也是把备份复制过去不能启动INNODB引擎请问楼主“改宿主名为nobody:nobody”这句是什么意思

#24

一次断电引发的innodb表空间错误，引发的innodb引擎全瘫血案，看了让人心惊肉跳。
你啥mysql版本，所有innodb表空间多少G？能给我么？
ibdata1, ib_logfile0、ib_logfile1

#25

show plugin
查看Innodb这条信息就表示安装好了。

如果没有安装成功或者是在已经安装好mysql的情况下，只要执行下面语句再安装一次就OK。
install plugin innodb soname 'ha_innodb.so' ;

#1

检查MYSQL的错误日志。

#2

1. 看看错误日志
2. 看看my.cnf中有什么实质的相关内容

#3

估计是ib_logfile文件坏了如果没备份要悲剧了

#4

请问linux版xampp的mysql的错误日志在哪啊？我怎么找不到。

#5

MySQL 5.1参考手册

5.11. MySQL日志文件
5.11.1. 错误日志
5.11.2. 通用查询日志
5.11.3. 二进制日志
5.11.4. 慢速查询日志
5.11.5. 日志文件维护
MySQL有几个不同的日志文件，可以帮助你找出mysqld内部发生的事情：

日志文件
记入文件中的信息类型

错误日志
记录启动、运行或停止mysqld时出现的问题。

查询日志
记录建立的客户端连接和执行的语句。

更新日志
记录更改数据的语句。不赞成使用该日志。

二进制日志
记录所有更改数据的语句。还用于复制。

慢日志
记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询。

默认情况下，所有日志创建于mysqld数据目录中。通过刷新日志，你可以强制 mysqld来关闭和重新打开日志文件（或者在某些情况下切换到一个新的日志）。当你执行一个FLUSH LOGS语句或执行mysqladmin flush-logs或mysqladmin refresh时，出现日志刷新。参见13.5.5.2节，“FLUSH语法”。

如果你正使用MySQL复制功能，从复制服务器将维护更多日志文件，被称为接替日志。相关讨论参见第6章：MySQL中的复制。

5.11.1. 错误日志
错误日志文件包含了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。

如果mysqld莫名其妙地死掉并且mysqld_safe需要重新启动它，mysqld_safe在错误日志中写入一条restarted mysqld消息。如果mysqld注意到需要自动检查或着修复一个表，则错误日志中写入一条消息。

在一些操作系统中，如果mysqld死掉，错误日志包含堆栈跟踪信息。跟踪信息可以用来确定mysqld死掉的地方。参见E.1.4节，“使用堆栈跟踪”。

可以用--log-error[=file_name]选项来指定mysqld保存错误日志文件的位置。如果没有给定file_name值，mysqld使用错误日志名host_name.err 并在数据目录中写入日志文件。如果你执行FLUSH LOGS，错误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项，则不会重新命名）。

如果不指定--log-error，或者(在Windows中)如果你使用--console选项，错误被写入标准错误输出stderr。通常标准输出为你的终端。

在Windows中，如果未给出--console选项，错误输出总是写入.err文件。

5.11.2. 通用查询日志
如果你想要知道mysqld内部发生了什么，你应该用--log[=file_name]或-l [file_name]选项启动它。如果没有给定file_name的值，默认名是host_name.log。所有连接和语句被记录到日志文件。当你怀疑在客户端发生了错误并想确切地知道该客户端发送给mysqld的语句时，该日志可能非常有用。
mysqld按照它接收的顺序记录语句到查询日志。这可能与执行的顺序不同。这与更新日志和二进制日志不同，它们在查询执行后，但是任何一个锁释放之前记录日志。(查询日志还包含所有语句，而二进制日志不包含只查询数据的语句）。

服务器重新启动和日志刷新不会产生新的一般查询日志文件(尽管刷新关闭并重新打开一般查询日志文件)。在Unix中，你可以通过下面的命令重新命名文件并创建一个新文件：

shell> mv hostname.log hostname-old.log
shell> mysqladmin flush-logs
shell> cp hostname-old.log to-backup-directory
shell> rm hostname-old.log
在Windows中，服务器打开日志文件期间你不能重新命名日志文件。你必须先停止服务器然后重新命名日志文件。然后，重启服务器来创建新的日志文件。

5.11.3. 二进制日志
二进制日志以一种更有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息。

二进制日志包含了所有更新了数据或者已经潜在

#6

#7

#8

你把IBDATA1都给删除了，INNODB的数据就全没有了。自然这些表就不存在了。

INNODB和MYISAM存储引擎不一样，它的数据是放在IBDATA中的。

#9

#10

做好备份。

然后在MY。INI文件中添加参数 innodb_force_recovery=1
试试，不行就加大这个数字，最大可以加到6.

提醒：做好备份。

#11

那我还要把ibdata1还原成原先那个吗？

这个备份是做哪个备份？数据库表？还是mysql的系统文件啊？

#12

那就备份整个目录，全备了。

#13

#14

把ibdata1恢复成以前的那个文件
然后逐步加这个innodb_force_recovery=1

#15

#16

#17

InnoDB: Unable to lock /opt/lampp/var/mysql/ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process

你是不是已经有一个MYSQLD进程启动了？

#18

没有啊。我每次都stop mysql的，而且我也查了。会不会是ibdata1这个文件损坏了啊？

#19

我用以前的ibdata1，在mysql里直接show engines，都没有innodb的纪录，have_innodb值都是no

#20

引用

没有啊。我每次都stop mysql的，而且我也查了。会不会是ibdata1这个文件损坏了啊？

#21

引用 20 楼 acmain_chm 的回复:

引用没有啊。我每次都stop mysql的，而且我也查了。会不会是ibdata1这个文件损坏了啊？应该是文件有问题。一般应该试着用 innodb_force_recovery=1试着恢复一下。但显然不是100%都能恢复。

恢复的时候，你需要原来的三个文件 ibdata1, ib_logfile0、ib_logfile1

#22

谢谢，搞定了，用了以前的ibdata1的备份文件，改宿主名为nobody:nobody，删掉ib_logfile0和1这两个文件。重启mysql，就ok了。不过这几天的记录都没了。

#23

引用 22 楼 nocturne1210 的回复:

谢谢，搞定了，用了以前的ibdata1的备份文件，改宿主名为nobody:nobody，删掉ib_logfile0和1这两个文件。重启mysql，就ok了。不过这几天的记录都没了。

我也碰到这问题了也是把备份复制过去不能启动INNODB引擎请问楼主“改宿主名为nobody:nobody”这句是什么意思

没有innodb。Unknown table engine 'InnoDB'

25 个解决方案

#1

#2

#3

#4

#5

#6

#7

#8

#9

#10

#11

#12

#13

#14

#15

#16

#17

#18

#19

#20

#21

#22

#23

#24

#25

#1

#2

#3

#4

#5

#6

#7

#8

#9

#10

#11

#12

#13

#14

#15

#16

#17

#18

#19

#20

#21

#22

#23

#24

#25

相关文章