Корисний "ХАК"

Стадия 1: проверка таблиц

Выполните myisamchk *.MYI или, если вы располагаете временем, myisamchk -e *.MYI. Используйте опцию -s (молчаливый режим) для подавления ненужной информации.

Если mysqld остановлен, то следует использовать опцию --update-state для указания myisamchk отмечать таблицы как ‘проверенные'(checked).

Ремонтировать следует только те таблицы, для которых myisamchk выдала ошибки. Для таких таблиц следует перейти к стадии 2.

Если во время проверки будут получены странные ошибки (подобные out of memory), или myisamchk завершится аварийно, то перейдите к стадии 3.

Стадия 2: легкий безопасный ремонт

Примечание: если есть желание ускорить ремонт, рекомендуется добавить: -O sort_buffer=# -O key_buffer=# (где # примерно 1/4 от имеющейся памяти) во всех командах isamchk/myisamchk.

Сначала надо попробовать запустить myisamchk -r -q tbl_name (-r -q означает “режим быстрого восстановления”). При этом будет сделана попытка исправить индексный файл без изменения файла данных. Если в файле данных содержится все необходимое, а удаленные связи указывают на правильные позиции в файле данных, то команда должна дать результат и таблица будет исправлена. Перейдите к ремонту следующей таблицы. В противном случае следует выполнить следующие действия:

1. Сделать резервную копию файла данных.
2. Использовать myisamchk -r tbl_name (-r означает “режим восстановления”). При этом из файла данных будут удалены некорректные и уничтоженные записи, и будет заново создан индексный файл.
3. Если на предыдущем шаге проблему решить не удастся, то используйте myisamchk --safe-recover tbl_name. В режиме безопасного восстановления используется старый метод восстановления, справляющийся с некоторыми случаями, которые оказываются не под силу для режима обычного исправления (но работает этот метод медленнее).

Если во время проверки будут получены странные ошибки (подобные out of memory) или myisamchk аварийно завершается, то перейдите к стадии 3.

Стадия 3: сложный ремонт

До этой стадии дело доходит, только если первый 16-килобайтный блок в индексном файле разрушен или содержит неверную информацию, либо когда индексный файл отсутствует. В этом случае необходимо создать новый индексный файл. Необходимо выполнить следующие действия:

1. Переместить файл данных в какое-нибудь безопасное место.
2. Использовать файл описания таблицы для создания новых (пустых) файлов – данных и индексного:

   shell> mysql db_name
   mysql> SET AUTOCOMMIT=1;
   mysql> TRUNCATE TABLE table_name;
   mysql> quit

   Если используемая версия SQL не располагает TRUNCATE TABLE, то взамен используется DELETE FROM table_name.

3. Скопируйте старый файл данных на место недавно созданного (делать перемещение старого файла обратно на место нового нецелесообразно, поскольку в старом файле может снова возникнуть потребность, если что-то пойдет не так).

Вернитесь к стадии 2. myisamchk -r -q теперь должна сработать (но бесконечно повторять стадии не следует).

Что касается MySQL 4.0.2, то тут можно воспользоваться REPAIR ... USE_FRM, выполняющей всю эту процедуру автоматически.

Стадия 4: очень сложный ремонт

До этой стадии вы дойдете только в случае, если ко всему прочему запорчен и файл описания. Такого происходить не должно, поскольку файл описания после создания таблицы не изменяется. Выполните следующие действия:

1. Восстановите файл описания из резервной копии и перейдите к стадии 3. Можно также восстановить индексный файл и вернуться к стадии 2. Во втором случае начинать надо с myisamchk -r.
2. Если резервной копии нет, но точно известно, как таблица создавалась, то создается копия таблицы в другой базе данных. Новый файл данных удаляется, затем файл описания с индексным файлом перемещаются из другой базы данных в поврежденную. Таким образом вы получаете новый файл описания и индексный файл, не затрагивая при этом файла данных. Делается возврат к стадии 2 с попыткой воссоздать индексный файл.

Теги: mysql

Дата написания: П’ятниця, 8 Квітня, 2011 о 22:07. Категорія Статьї.