gpt4 book ai didi

mysql - 异常的 mysql frm 和 idb 文件

转载 作者:行者123 更新时间:2023-11-29 03:04:30 25 4
gpt4 key购买 nike

我启用了 innodb_file_per_table 选项,因此每个表都有一个 .frm 和一个 .ibd 文件。不寻常的是还有一些文件似乎来自文件系统上的临时表:

/db/mysql$ ls
<snip>
#sql2-25fe-5.frm
#sql2-25fe-5.ibd
#sql2-55f4-73.frm
#sql2-55f4-73.ibd
#sql-55f6_13b626.ibd
#sql-6abe_e3.ibd
</snip>

其中一个相当大,所以如果安全的话我想摆脱它们。我尝试像删除常规表和临时表一样删除它们,但不管怎样都行不通。

drop table `#sql2-25fe-5`;
drop temporary table `#sql2-25fe-5`;

有什么想法吗?谢谢

最佳答案

只是为了解决这个问题:

转储并重新加载所有表释放了我想要的空间(innobackupex 备份和恢复不起作用)。我相信这些永久临时表是 mysql 中已修复的两个错误之一的结果:

InnoDB: If the server crashed at a precise moment during an ALTER TABLE operation that rebuilt the clustered index for an InnoDB table, the original table could be inaccessible afterward. An example of such an operation is ALTER TABLE ... ADD PRIMARY KEY The fix preserves the original table if the server halts during this operation. You might still need to rename the .ibd file manually to restore the original table contents: in MySQL 5.6 and higher, rename from #sql-ib$new_table_id.ibd to table_name.ibd within the database directory; prior to MySQL 5.6, the temporary file to rename is table_name#1 or #2. (Bug #14669848)

https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-30.html

InnoDB: For UPDATE statements in which an error occurred, it was possible for a temporary file opened during the update not to be closed. (Bug #15978766)

https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-32.html

关于mysql - 异常的 mysql frm 和 idb 文件,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17982184/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com