4

約 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)

問題があるようです。今、何をすべきかを解決します。修復クエリを強制終了するのは気が進まないのですが、強制する必要があるかもしれません...

4

1 に答える 1

6

http://dev.mysql.com/doc/refman/5.5/en/kill.html言います:

警告: MyISAM テーブルで REPAIR TABLE または OPTIMIZE TABLE 操作を強制終了すると、テーブルが破損して使用できなくなります。そのようなテーブルへの読み取りまたは書き込みは、(中断することなく) 再度最適化または修復するまで失敗します。

したがって、それを強制終了することはできますが、修復を再度実行する必要があり、修復できなくなるリスクがあります。その場合は、最新のバックアップから復元する必要があり、バイナリ ログを使用してポイント イン タイム リカバリの実行を試みることができます。

このREPAIR TABLE操作には、修復しようとしているテーブルの約 2 倍のディスク領域が必要です。

REPAIR TABLEconfig 変数で定義された場所にある一時ストレージを使用しますtmpdir。を開始する前に、この変数を十分なディスク容量があるパーティションに変更してくださいREPAIR TABLE。 Tmpdirは動的変数ではないため、変更するには mysqld を再起動する必要があります。

この同様の質問を参照してください: https://dba.stackexchange.com/questions/11352/repairing-myisam-table-when-there-was-no-additional-disk-space-table-corrupted

もう 1 つのアドバイス: MyISAM の代わりに InnoDB の使用を検討してください。

于 2013-01-21T20:42:22.457 に答える