如何从“不正确的密钥文件”中恢复 与MySQL(InnoDB)?

发布于 2024-07-25 02:16:10 字数 892 浏览 5 评论 0原文

Incorrect key file for table 'widgets'; try to repair it 

这是 MySQL 在尝试将新索引应用于现有(非常大)表时给出的错误消息。 当然,当我按照错误消息的建议尝试修复它时:

mysql> repair table widgets;
+-------------------+--------+----------+---------------------------------------------------------+
| Table             | Op     | Msg_type | Msg_text                                                |
+-------------------+--------+----------+---------------------------------------------------------+
| tedsdb.widgets    | repair | note     | The storage engine for the table doesn't support repair | 
+-------------------+--------+----------+---------------------------------------------------------+
1 row in set (0.00 sec)

这里我最好的操作方案是什么(在修补之前遵循明显的完整备份)?

更新:我创建了一个具有相同架构的新表(MyISAM),复制了所有记录(插入到选择中),更改了新表(InnoDB)上的引擎,重命名了损坏的表并重命名新表,然后再次尝试并得到相同的错误。

Incorrect key file for table 'widgets'; try to repair it 

This is the error message MySQL gives me when attempting to apply a new index to an existing (very large) table. Of course when I follow the error message's suggestion of trying to repair it:

mysql> repair table widgets;
+-------------------+--------+----------+---------------------------------------------------------+
| Table             | Op     | Msg_type | Msg_text                                                |
+-------------------+--------+----------+---------------------------------------------------------+
| tedsdb.widgets    | repair | note     | The storage engine for the table doesn't support repair | 
+-------------------+--------+----------+---------------------------------------------------------+
1 row in set (0.00 sec)

What's my best course of action here (following the obvious full backup before tinkering)?

UPDATE: I created a new table (MyISAM) of the same schema, copied over all the records (insert into select), the changed the engine on the new table (InnoDB), renamed the corrupt table and renamed the new table, then tried again and got the same error.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

醉梦枕江山 2024-08-01 02:16:10

看起来像是一个老问题,但我刚刚遇到了这个问题。 MySQL 正在将临时表写入磁盘,并且 /tmp 分区已满。

Looks like an old question, but I just ran into this problem. MySQL was writing out a temporary table to disk and the /tmp partition filled up.

拥抱影子 2024-08-01 02:16:10

我强烈建议在尝试此操作之前进行备份

进行假人表演

ALTER TABLE widgets;

I strongly suggest backing up before trying this.

Perform a dummy

ALTER TABLE widgets;
灯下孤影 2024-08-01 02:16:10

当我们在 innodb 上进行 Alter 操作时,需要观察“tmpdir”。 错误 1034 :密钥修复肯定是因为“tmpdir”已满,并且您的更改会抛出此错误。

因此,我建议当 Alter 被触发时,请多关注您的“tmpdir”利用率。 如果 tmp 使用 100%,您肯定会看到此错误:)。

When we are doing Alter on innodb the "tmpdir" need to be observed. The Error 1034 : Key repair is definitely because of "tmpdir" full, and your alter will throw this error.

So I suggest when the Alter is got triggered give one more eye on your "tmpdir" utilization. If tmp is using 100% there you can see this error for sure :).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文