B.5.4.3 MySQL が満杯のディスクを処理する方法

このセクションでは、MySQL がディスク満杯エラー (デバイスに領域が残っていないなど)、および割り当て超過エラー (書き込みに失敗しましたユーザーブロックの制限に達しましたなど) に対処する方法について説明します。

このセクションは、MyISAM テーブルへの書き込みに関連しています。およびレコードへの言及がイベントを意味すると理解する必要があることを除き、バイナリログファイルおよびバイナリログインデックスファイルへの書き込みにも当てはまります。

ディスク満杯状態が発生すると、MySQL は次のことを行います。

  • 現在の行を書き込むための十分な領域があるかどうかを 1 分おきに確認します。十分な領域がある場合は、何事もなかったかのように稼働し続けます。

  • ディスク満杯状態について警告するエントリをログファイルに 10 分おきに書き込みます。

問題を軽減するには次のアクションを行います。

  • 続行する場合は、すべてのレコードを挿入するための十分なディスク領域を解放する必要があるだけです。

  • または、スレッドを中止するには mysqladmin kill を使用します。スレッドは次回ディスクがチェックされるとき (1 分以内) に中止されます。

  • ほかのスレッドが、ディスク満杯状態の原因となったテーブルを待機している可能性があります。複数のロックされたスレッドがある場合は、ディスク満杯状態を待機していた 1 つのスレッドを強制終了すると、ほかのスレッドが続行できるようになります。

前述の動作の例外は、REPAIR TABLE または OPTIMIZE TABLE を使用する場合、あるいは LOAD DATA INFILE またはALTER TABLE ステートメントのあとにインデックスがバッチで作成される場合です。これらのすべてのステートメントでは大きい一時ファイルが作成されることがあり、それがそのまま残された場合、システムのほかの部分で大きな問題となる可能性があります。MySQL がこれらのいずれかの操作を実行していて、ディスクが満杯になった場合は、大きい一時ファイルが削除され、テーブルがクラッシュとしてマークされます。例外は ALTER TABLE の場合で、古いテーブルは変更されないままになります。


User Comments
  Posted by Yurii Zborovs'kyi on May 5, 2003
Another exception is a SELECT with GROUP at several joins, where each of the table has a couple of millions rows and each of them is actually full-scanned.

Example: linguistic task to find (some top of) spreads of combinations of 2, 3, 4, 5 patterns each of 'A%' type (all words with 1st letter same).

When I was calculated comb of 4 patterns, the query was almost 5 hours long (@1.1GHz Athlon) and required about 1.6 Gb of free memory at tmpdir disk (measured after first get my query aborted due to full disk)!

Do you fill power? ;-)

jz

  Posted by J Jorgenson on July 17, 2006
Be aware that the Database does NOT return until there is disk space, or the thread is *manually* killed.

It would be nice to have the option to (programatically) 'abort' a SQL query, sooner than later, when there is not sufficient disk space.

We've had processes 'hang' for hours until the DBA noticed a full disk situation. Once the disk space was freed, THEN the thread generated an error (go figure?).

  Posted by Galt Barber on August 24, 2006
On our linux servers, it is defaulting to /tmp which is not a large volume on our servers. When making indexes on big tables (80 million rows 3GB data, 1.5GB index), show processlist starts out saying "Repair with sorting" but soon switches to the dreaded "Repair by keycache", which means it does not fail with an error message but continues, albeit very very slowly (12 hours). To fix the problem we just restarted the mysqld server using a larger temp directory with --tmpdir=/plenty-of-space-here and that is so much better! Just 28 minutes now!
You can also set $TMPDIR instead. See the documentation.

See also http://bugs.mysql.com/bug.php?id=1320

  Posted by Bas Meijer on September 17, 2007
There is no way to symlink to a new SAN mount, there is an open filehandle there. If only myisamchk would open the $TMPDIR paths in order as suggested by the man page, or if it would try to create the tmpfile anew with the path in the error then I could create a big enough disk without interupting the repair
(with a 100Gb table you get tired of waiting for mysql)
Sign Up Login You must be logged in to post a comment.