主页 / dba / 问题 / 6859
Accepted
Alaa
Asked: 2011-10-17 01:10:51 +0800 CST

查询时出现错误“未知表引擎 'InnoDB'”。重启mysql后

  • 772

我在服务器 S1 上有 mysql DB（mysql 版本 5.1.41-3ubuntu12.7-log）。

我在服务器 S2（mysql 版本 5.1.54-1ubuntu4-log）上为这个数据库创建了主从。

S1 上的数据库使用一个数据文件 (ibdata)。

将 DB 转储到 S2 后，我设置了innodb_file_per_table=1. 这使得每个表都有自己的 ibd 文件。现在一切顺利。

在 S2 上重新启动 mysql 后，我遇到了收到此错误的问题：
Error 'Unknown table engine 'InnoDB'' on query. Default database: MyDB 当我尝试显示引擎时，我得到以下信息：

展示引擎；
+------------+---------+-------------- --------------------------------------------------+------------ ---+--------+------------+
| 引擎 | 支持 | 评论 | 交易 | XA | 保存点 |
+------------+---------+-------------- --------------------------------------------------+------------ ---+--------+------------+
| MyISAM | 默认 | MySQL 3.23 的默认引擎具有出色的性能| 否 | 否 | 否 |
| MRG_MYISAM | 是 | 相同的 MyISAM 表的集合 | 否 | 否 | 否 |
| 黑洞 | 是 | /dev/null 存储引擎（您写入的任何内容都会消失）| 否 | 否 | 否 |
| CSV | 是 | CSV 存储引擎 | 否 | 否 | 否 |
| 内存 | 是 | 基于哈希，存储在内存中，对临时表有用 | 否 | 否 | 否 |
| 联邦 | 否 | 联合 MySQL 存储引擎 | 空 | 空 | 空 |
| 存档 | 是 | 归档存储引擎 | 否 | 否 | 否 |
+------------+---------+-------------- --------------------------------------------------+------------ ---+--------+------------+

InnoDB 未列出。

在错误日志中，我可以看到：

InnoDB：数据库物理写入文件已满：等待...
InnoDB：无法初始化创建的日志文件，因为
InnoDB：数据文件已损坏，或新数据文件已损坏
InnoDB：在数据库之前启动时创建
InnoDB：时间但数据库没有关闭
InnoDB：通常在那之后。
111016 8:24:11 [错误] 插件“InnoDB”初始化函数返回错误。
111016 8:24:11 [错误] 插件“InnoDB”注册为存储引擎失败。
111016 8:24:11 [警告] 既没有使用 --relay-log 也没有使用 --relay-log-index；因此，当此 MySQL 服务器充当从属服务器并更改其主机名时，复制可能会中断！请使用 '--relay-log=S2-relay-bin' 来避免这个问题。

我试图删除 ib_logfiles 但这也不起作用。如果我删除 ib_logfiles 和 ibdata 文件，innodb 将正常返回，但我无法访问我的 innodb 表，即。删除ibdata1并重新启动mysql后

描述文章；
错误 1146 (42S02)：表 'MyDb.article' 不存在

我在 my.cnf 中的 innodb 配置如下： 

innodb_file_per_table=1  
innodb_flush_method=O_DIRECT  
innodb_log_file_size=1G  
innodb_buffer_pool_size=4G  
innodb_data_file_path=ibdata1:10M:autoextend  
innodb_buffer_pool_size = 384M  
innodb_log_file_size=5M  
innodb_lock_wait_timeout = 18000

虽然桌子在那里！！

以前有人遇到过这样的问题吗？？

任何想法都受到高度赞赏

谢谢

mysql replication

3 个回答

  1. Best Answer

    我有一个非常坏的消息要告诉你。

    您不应该删除 ibdata1 文件。原因如下：

    ibdata1 包含四种类型的信息：

    • 表元数据
    • MVCC 数据
    • 数据页（启用 innodb_file_per_table）
    • 索引页（启用了 innodb_file_per_table）

    创建的每个 InnoDB 表都有一个数字 id，通过一些自动增量元数据功能分配给每个 ibd 文件。该内部表空间 ID (ITSID) 嵌入在 .ibd 文件中。对照维护的 ITSID 列表检查该数字，猜猜在哪里，... ibdata1。

    我也有一个非常好的消息要告诉你，还有一些坏消息。

    可以重建 ibdata1 以获得正确的 ITSID，但要做到这一点需要工作。虽然我个人并没有单独完成程序，但我协助我雇主的虚拟主机的客户完成了这项工作。我们一起解决了这个问题，但由于客户端使用了 ibdata1，我让他完成了大部分工作（30 个 InnoDB 表）。

    无论如何，这是我在 DBA StackExchange 上发表的一篇文章。我回答了另一个问题，其根本原因是 ITSID 的混淆。

    切入正题，这里是解释如何参考 ITSID 以及如何按摩 ibdata1 以确认 .ibd 文件中包含的 ITSID 的存在的文章。

    很抱歉，除了玩带有 ITSID 的游戏之外，没有快速而简单的方法来恢复 .ibd 文件。

    更新 2011-10-17 06:19 EDT

    这是您问题中的原始 innodb 配置：

    innodb_file_per_table=1
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_buffer_pool_size = 384M
innodb_log_file_size=5M
innodb_lock_wait_timeout = 18000

    请注意 innodb_log_file_size 有两次。仔细看...

    innodb_file_per_table=1
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G <----
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_buffer_pool_size = 384M
innodb_log_file_size=5M <----
innodb_lock_wait_timeout = 18000

    innodb_log_file_size 的最后一个设置优先。MySQL 预计以 5M 的日志文件启动。当您尝试启动 mysqld 时，您的 ib_logfile0 和 ib_logfile1 为 1G。它看到了大小冲突并采取了阻力最小的路径，即禁用 InnoDB。这就是为什么 InnoDB 从show engines;. 谜团已揭开 ！！！

    更新 2011-10-17 11:07 EDT

    该错误消息具有欺骗性，因为 innodb_log_file_size 小于当时为 1G 的日志文件（ib_logfile0 和 ib_logfile1）。有趣的是：由于文件预计为 5M 并且文件更大，因此报告了损坏。如果情况相反并且 innodb 日志文件小于 my.cnf 中声明的大小，您应该在错误日志中得到类似的内容：

    110216 9:48:41 InnoDB: Initializing buffer pool, size = 128.0M
110216 9:48:41 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 33554432 bytes!
110216 9:48:41 [ERROR] Plugin 'InnoDB' init function returned error.
110216 9:48:41 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

    在此示例中，日志文件已存在 5M，并且 innodb_log_file_size 的设置更大（在本例中为 32M）。

    对于这个特定的问题，我将不一致的错误消息协议归咎于 MySQL（呃 Oracle [仍然讨厌这样说]）。

    • 6

  2. 错误日志表明您有一些数据损坏。发生这种情况时，InnoDB 不会在SHOW ENGINES. 您可以尝试通过执行以下步骤强制恢复：

    • 在 S2 上关闭 mysql
    • 添加innodb_force_recovery=1到您的 my.cnf 文件
    • 启动 mysql 并查看是否列出了您的数据。

    希望它在那里，您可以减少数据并将其重新加载到 S2 上。

    • 4

  3. 就我而言，使用innodb_force_recovery=1不起作用。然后我发现有第二个 mysql 实例正在运行，它不接受任何连接并且杀戮-1不起作用，所以我选择重新启动服务器。

    重新启动后，我跑了start slave，一切都自行恢复正常。

    • 0

相关问题