由于空间问题,MySQL REPAIR TABLE停滞不前

ras*_*oym 4 mysql

大约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
Run Code Online (Sandbox Code Playgroud)

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)
Run Code Online (Sandbox Code Playgroud)

似乎是问题所在.现在来弄清楚要做什么.我不愿意杀死修复查询,但可能不得不...

Bil*_*win 6

http://dev.mysql.com/doc/refman/5.5/en/kill.html说:

警告:在MyISAM表上终止REPAIR TABLE或OPTIMIZE TABLE操作会导致表已损坏且无法使用.对此类表的任何读取或写入都会失败,直到您再次优化或修复它(不中断).

所以你可以杀死它,但你必须再次进行修复,并且存在无法修复的风险.如果发生这种情况,您必须从最新的备份还原,并且可以尝试使用二进制日志执行时间点恢复.

REPAIR TABLE操作需要的磁盘空间大约是它尝试修复的表的两倍.

REPAIR TABLE在config变量定义的位置使用临时存储tmpdir.确保在启动之前将此变量更改为存在大量磁盘空间的分区REPAIR TABLE. Tmpdir不是动态变量,因此您必须重新启动mysqld才能更改它.

看到类似的问题:https://dba.stackexchange.com/questions/11352/repairing-myisam-table-when-there-was-no-additional-disk-space-table-corrupted

另一条建议:考虑使用InnoDB而不是MyISAM.

  • 非常感谢!这就是我所做的:(1)杀死了REPAIR(2)更改了tmpdir变量(3)再次执行REPAIR.一切都很好. (2认同)