A.4.3 How MySQL Handles a Full Disk

When a disk-full condition occurs, MySQL does the following:

• It checks once every minute to see whether there is enough space to write the current row. If there is enough space, it continues as if nothing had happened.
• Every 6 minutes it writes an entry to the log file warning about the disk full condition.

To alleviate the problem, you can take the following actions:

• To continue, you only have to free enough disk space to insert all records.
• To abort the thread, you must send a mysqladmin kill to the thread. The thread will be aborted the next time it checks the disk (in 1 minute).
• Note that other threads may be waiting for the table that caused the disk full condition. If you have several ``locked'' threads, killing the one thread that is waiting on the disk-full condition will allow the other threads to continue.

Exceptions to the above behaveour is when you use REPAIR or OPTIMIZE or when the indexes are created in a batch after an LOAD DATA INFILE or after an ALTER TABLE statement.

All of the above commands may use big temporary files that left to themself would cause big problems for the rest of the system. If MySQL gets disk full while doing any of the above operations, it will remove the big temporary files and mark the table as crashed (except for ALTER TABLE, in which the old table will be left unchanged).

User Comments

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

Add your own comment.