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 not find file tbl_name.MYI (Errcode: ###) (Не можу знайти файл tbl_name.MYI (Помилка: ###))
Unexpected end of file (Несподівано настав кінець)
Record file is crashed (Файл записів зіпсований)
Got error ### from table handler (Отримано помилку ### від дескриптора таблиці). Для отримання більш докладної інформації про помилку можна виконати perror ###. Найчастіше про проблеми з таблицею свідчать наступні помилки:
Зауважимо, що помилка 135 - 'no more room in record file' ( 'не залишилося місця в файлі записів'), не може бути виправлена просто виконанням ремонту. У цьому випадку необхідно використовувати наступну команду:
В інших випадках слід виконувати ремонт таблиць. myisamchk зазвичай може виявити і виправити більшість неполадок.
Процес ремонтування включає до чотирьох описаних тут стадій. Перед тим як приступити до ремонту, необхідно виконати cd в каталог бази даних і перевірити права доступу до табличних файлів. Файли повинні бути доступні для читання Unix-користувачеві, від імені якого виконується mysqld. (А також виконує ремонт, оскільки йому доводиться звертатися до перевіряється файлів). Якщо з'явиться необхідність змінювати файли, то перевіряючий також повинен мати доступ для запису.
Якщо використовується версія MySQL 3.23.16 і вище, то для перевірки і ремонту таблиць MyISAM можна (і потрібно) використовувати команди CHECK і REPAIR (Розділ 4.4.4, «Синтаксис CHECK TABLE» і see Розділ 4.4.5, «Синтаксис REPAIR TABLE» ).
Випадки, коли згадані команди не дають результату або бажано використовувати розширені можливості, представлені в 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 означає "режим швидкого відновлення"). При цьому буде зроблено спробу виправити індексний файл без зміни файлу даних. Якщо у файлі даних міститься все необхідне, а віддалені зв'язку вказують на правильні позиції в файлі даних, то команда повинна дати результат і таблиця буде виправлена. Перейдіть до ремонту наступній таблиці. В іншому випадку слід виконати наступні дії:
Зробити резервну копію файлу даних.
Використовувати myisamchk -r tbl_name (-r означає "режим відновлення"). При цьому з файлу даних будуть видалені некоректні і знищені записи, і буде заново створено індексний файл.
Якщо на попередньому кроці проблему вирішити не вдасться, то використовуйте myisamchk --safe-recover tbl_name. У режимі безпечного відновлення використовується старий метод відновлення, справляється з деякими випадками, які виявляються не під силу для режиму звичайного виправлення (але працює цей метод повільніше).
Якщо під час перевірки будуть отримані дивні помилки (подібні out of memory) або myisamchk аварійно завершується, то перейдіть до стадії 3.
Стадія 3: складний ремонт
До цієї стадії справа доходить, тільки якщо перший 16-кілобайтний блок в індексному файлі зруйнований або містить невірну інформацію, або коли індексний файл відсутній. В цьому випадку необхідно створити новий індексний файл. Необхідно виконати наступні дії:
Перемістити файл даних в яке-небудь безпечне місце.
Використовувати файл опису таблиці для створення нових (порожніх) файлів - даних і індексного:
Якщо використовувана версія SQL не має TRUNCATE TABLE. то замість використовується DELETE FROM table_name.
Скопіюйте старий файл даних на місце недавно створеного (робити переміщення старого файлу назад на місце нового недоцільно, оскільки в старому файлі може знову виникнути потреба, якщо щось піде не так).
Поверніться до стадії 2. myisamchk -r -q тепер повинна спрацювати (але нескінченно повторювати стадії не слід).
Що стосується MySQL 4.0.2, то тут можна скористатися REPAIR. USE_FRM. виконує всю цю процедуру автоматично.
Стадія 4: дуже складний ремонт
До цієї стадії ви дійдете тільки в разі, якщо до всього іншого пошкоджений і файл опису. Такого відбуватися не повинно, оскільки файл опису після створення таблиці не змінюється. Виконайте наступні дії:
Відновіть файл опису з резервної копії і перейдіть до стадії 3. Можна також відновити індексний файл і повернутися до стадії 2. У другому випадку починати треба з myisamchk -r.
Якщо резервної копії немає, але точно відомо, як таблиця створювалася, то створюється копія таблиці в іншій базі даних. Новий файл даних видаляється, потім файл опису з індексним файлом переміщаються з іншої бази даних в пошкоджену. Таким чином ви отримуєте новий файл опису та індексний файл, не зачіпаючи при цьому файлу даних. Робиться повернення до стадії 2 зі спробою відтворити індексний файл.