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

Начал смотреть, чем занято место на сервере. Помимо веб-контента, достаточно много занимали базы 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 с лишним МБ.

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