我在4天前开始了一个REPAIR TABLE:
Query | 351804 | Repair by sorting | REPAIR TABLE
它使用了磁盘上的所有空间:
/dev/md0 9.2G 8.8G 0 100% /
一旦删除了某些内容,空间就会很快耗尽。我现在用完了我可以删除的东西。此外,我无法解决所有空间已经消失的地方:
dispus v2.4 - Reading usage in /
Ignoring mount points: proc sys home
9,133,044 KB used of 9,621,752 KB available (100%)
1. 1,859,308 KB usr
2. 1,142,836 KB var
3. 274,692 KB lib
4. 35,924 KB root
5. 25,308 KB boot
6. 19,756 KB sbin
7. 18,400 KB lib64
8. 15,936 KB etc
9. 6,732 KB bin
etc
mysql数据目录位于不同的分区上。
任何人都有任何想法如何让这个REPAIR完成?
*的 更新 **
lsof | grep deleted
mysqld 20862 mysql 189u REG 9,0 4724886042 81629 /tmp/STqCaElP (deleted)
mysqld 20862 mysql 201u REG 9,0 1107226624 81633 /tmp/STWfcUNu (deleted)
似乎是问题所在。现在来弄清楚要做什么。我不愿意杀死修复查询,但可能不得不......
答案 0 :(得分:5)
http://dev.mysql.com/doc/refman/5.5/en/kill.html说:
警告:在MyISAM上终止REPAIR TABLE或OPTIMIZE TABLE操作 table会导致表已损坏且无法使用。任何阅读或 写入此类表会失败,直到您再次优化或修复它为止 (没有中断)。
所以你可以杀死它,但你必须再次进行修复,而且存在无法修复的风险。如果发生这种情况,您必须从最新的备份中恢复,并且可以尝试使用二进制日志执行point-in-time recovery。
REPAIR TABLE
操作所需的磁盘空间大约是它尝试修复的表的两倍。
REPAIR TABLE
在配置变量tmpdir
定义的位置使用临时存储。确保在启动REPAIR TABLE
之前将此变量更改为存在大量磁盘空间的分区。 Tmpdir
不是动态变量,因此您必须重新启动mysqld才能更改它。
另一条建议:考虑using InnoDB instead of MyISAM.