Заметка по горячим следам.

Начал смотреть, чем занято место на сервере. Помимо веб-контента, достаточно много занимали базы ejabberd’а – порядка 1 ГБ для jabberworld. Половина объема – archive (таблица для хранения сообщений). Держа в голове мысль о том, что архив на деле может быть меньше – ведь в cron’е теперь идет его периодическая чистка – я поискал команды для возможности уменьшения занимаемого таблицей места на диске. Для этого есть

optimize table archive;

На что получил несколько сообщений:

| Table does not support optimize, doing recreate + analyze instead

| Index for table 'archive' is corrupt; try to repair it

| Operation failed

“Наверное, битый индекс тянется еще с каких-то старых времен” – подумал я. Начал искать решения.

Для таблицы, кстати, было с десяток индексов – можно глянуть по show indexes from archive.

repair table archive выдал в ответ The storage engine for the table doesn't support repair.

check table archive и analyze table archive выдавал OK в статусе.

alter table archive engine = InnoDB тоже выдавал ошибку индексов.

Найденный в сети вариант reindex table archive у меня не работал – ошибка синтаксиса.

Оставалось полное пересоздание таблицы. Решил потренироваться “на кошках” – создать сначала просто копию таблицы. Открыл для себя несколько новых команд:

create table archive2 like archive

insert into archive2 select * from archive ;
ERROR 3 (HY000): Error writing file '/tmp/#sql/fd=524' (Errcode: 28 "No space left on device")

А вот это уже интересно. Сходу в соседней консоли глянул сначала место по обычным дискам, но там все ок. Вчитался. /tmp. Он в tmpfs и (был) 256 МБ. Перемонтировал, увеличив место. Копия таблицы успешно создалась. Не тут ли проблема и с индексами? А точнее – с ее отсутствием вообще? Запустил снова optimize table archive – в этот раз все прошло без ошибок. В процессе наблюдал занимаемое место в /tmp – до 400 с лишним МБ.

А ларчик просто открывался.