Как починить упавшую таблицу MySQL в WordPress

Это случилось с одним из старых сайтов, которые мы обслуживаем. Он сломался без нормального кода ошибки: ни внятного сообщения, ни stack trace, просто сломанный сайт. Свалить всё на базу данных было обоснованной догадкой. И, как оказалось, верной:

Table ’./database_name/wp_options’ is marked as crashed and last (automatic?) repair failed

Обратите внимание на вопросительный знак в “(automatic?)”. Даже MySQL не уверен, что именно он пытался сделать. В переводе на человеческий: таблица записалась наполовину, MySQL ей больше не доверяет, а его собственная починка не сработала.

Что означает “упавшая таблица”?

Таблица повреждается, когда у операции записи внезапно выдёргивают почву из-под ног. Обычные подозреваемые:

• Серверу не хватило места на диске прямо во время записи
• Неожиданная перезагрузка сервера или отключение питания
• Проблемы с накопителем
• Процесс MySQL был убит во время обновления

MySQL это замечает, помечает таблицу как “crashed” и пытается починить её сам. Если и это не срабатывает, вы получаете ошибку выше, и дальше ваш ход.

Как определить проблему

Если сайт не говорит ничего полезного (мой не говорил), спросите MySQL напрямую:

CHECK TABLE wp_options;

Если таблица повреждена, в результатах вы увидите статус вроде Table is marked as crashed.

Решение

Выполните эту SQL-команду через phpMyAdmin или ваш клиент MySQL:

REPAIR TABLE wp_options USE_FRM;

Флаг USE_FRM указывает MySQL пересобрать структуру таблицы, используя файл .frm (описание таблицы), даже если файл индекса повреждён. Это более агрессивный способ, чем стандартное восстановление, и работает там, где автоматическое восстановление не справилось.

Важно для MySQL 8.0+: файлов .frm там больше нет, но USE_FRM по-прежнему работает: заголовок индекса пересобирается из словаря данных. Сначала попробуйте обычный REPAIR TABLE wp_options;, потому что USE_FRM ещё и сбрасывает счётчик AUTO_INCREMENT.

Вы должны увидеть вывод, подтверждающий успешное восстановление:

Советы по профилактике

• Следите за местом на диске — большинство падений случаются, когда серверу не хватает свободного места
• Используйте InnoDB — она справляется с падениями куда изящнее, чем MyISAM
• Регулярные бэкапы — иногда повреждение уничтожает данные, которые не восстановит даже repair

Когда восстановления недостаточно

Если и REPAIR TABLE не помогает, остаётся восстанавливать из бэкапа или пересобирать таблицу с нуля. А wp_options — это где WordPress хранит URL сайта, активные плагины и настройки темы, так что “с нуля” — сомнительное удовольствие на целый вечер. Делайте бэкапы. Чеклист безопасности WordPress не зря начинается именно с них.

Страшная с виду ошибка, одна строчка SQL. А настоящее решение — скучное: следите за местом на диске и делайте бэкапы.