П О Р Т А Л                            
С Е Т Е В Ы Х                          
П Р О Е К Т О В                        
  
Поиск по сайту:
                                                 
Главная

О проекте

Web-мастеру
     HTML & JavaScript
     SSI
     Perl
     PHP
     XML & XSLT
     Unix Shell

MySQL

Безопасность

Хостинг

Другое








Самое читаемое:

Учебник PHP - "Для Чайника".
Просмотров 179486 раз(а).

Иллюстрированный самоучитель по созданию сайтов.
Просмотров 77402 раз(а).

Учебник HTML.
Просмотров 75096 раз(а).

Руководство по PHP5.
Просмотров 46126 раз(а).

Хостинг через призму DNS.
Просмотров 53362 раз(а).

Подборка текстов стандартных документов.
Просмотров 46118 раз(а).

Учебник PHP - Самоучитель
Просмотров 52277 раз(а).

Документация на MySQL (учебник & справочное руководство)
Просмотров 52826 раз(а).

Внешние атаки...
Просмотров 42751 раз(а).

Учебник PHP.
Просмотров 38258 раз(а).

SSI в примерах.
Просмотров 28371 раз(а).



 
 
| Добавить в избранное | Сделать стартовой | Помощь





Глава 4. Администрирование баз данных
Пред. След.

4.4. Предотвращение катастроф и восстановление
4.4.6. Использование myisamchk для профилактики таблиц и послеаварийного восстановления

4.4.6.9. Как ремонтировать таблицы

В данном разделе рассматривается только использование myisamchk на таблицах MyISAM (расширения .MYI и .MYD). Если же в системе применяются таблицы ISAM (расширения .ISM и .ISD), то следует пользоваться isamchk.

Начиная с версии MySQL 3.23.14 можно ремонтировать таблицы MyISAM при помощи команды REPAIR TABLE (see Раздел 4.4.5, «Синтаксис REPAIR TABLE »).

К симптомам повреждения таблицы относятся неожиданные прерывания выполнения запросов и появление следующих ошибок:

  • tbl_name.frm is locked against change (Файл заблокирован для изменений)

  • Can't find file tbl_name.MYI (Errcode: ###) (Не могу найти файл tbl_name.MYI (Ошибка: ###))

  • Unexpected end of file (Неожиданно наступил конец)

  • Record file is crashed (Файл записей испорчен)

  • Got error ### from table handler (Получена ошибка ### от дескриптора таблицы). Для получения более подробной информации об ошибке можно выполнить perror ###. Чаще всего о проблемах с таблицей свидетельствуют следующие ошибки:

    shell> perror 126 127 132 134 135 136 141 144 145
    126 = Index file is crashed / Wrong file format
    127 = Record-file is crashed
    132 = Old database file
    134 = Record was already deleted (or record file crashed)
    135 = No more room in record file
    136 = No more room in index file
    141 = Duplicate unique key or constraint on write or update
    144 = Table is crashed and last repair failed
    145 = Table was marked as crashed and should be repaired
    

    Заметим, что ошибка 135 - 'no more room in record file' ('не осталось места в файле записей'), не может быть исправлена просто выполнением ремонта. В этом случае необходимо использовать следующую команду:

    ALTER TABLE table MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;
    

В других случаях следует выполнять ремонт таблиц. myisamchk обычно может обнаружить и исправить большинство неполадок.

Процесс ремонтирования включает до четырех описанных здесь стадий. Перед тем как приступить к ремонту, необходимо выполнить cd в каталог базы данных и проверить права доступа к табличным файлам. Файлы должны быть доступны для чтения Unix-пользователю, от имени которого выполняется mysqld, (а также выполняющему ремонт, поскольку ему приходится обращаться к проверяемым файлам). Если появится необходимость изменять файлы, то проверяющий также должен иметь доступ для записи.

Если используется версия MySQL 3.23.16 и выше, то для проверки и ремонта таблиц MyISAM можно (и нужно) использовать команды CHECK и REPAIR (Раздел 4.4.4, «Синтаксис CHECK TABLE » и see Раздел 4.4.5, «Синтаксис REPAIR TABLE »).

Раздел руководства, посвященный сопровождению таблиц, содержит опции к isamchk/myisamchk (see Раздел 4.4.6, «Использование myisamchk для профилактики таблиц и послеаварийного»).

Случаи, когда упомянутые команды не дают результата или желательно использовать расширенные возможности, представленные в isamchk/myisamchk, рассматриваются в следующем разделе.

Если ремонт таблицы планируется выполнять из командной строки то сначала требуется остановить сервер. Следует отметить, что при выполнении mysqladmin shutdown с удаленного сервера mysqld все еще будет некоторое время работать после завершения mysqladmin, пока не будут остановлены все запросы и сброшены на диск все ключи.

Стадия 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 с попыткой воссоздать индексный файл.


Назад Начало Главы Начало Раздела Начало Подраздела Вперед

Пред. Глава След. Глава
Глава 3. Учебное пособие по MySQL Начало Книги Глава 5. Оптимизация в MySQL


Если Вы не нашли что искали, то рекомендую воспользоваться поиском по сайту:
 





Copyright © 2005-2016 Project.Net.Ru