Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
REPAIR [NO_WRITE_TO_BINLOG | LOCAL] TABLEtbl_name[,tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]
REPAIR
TABLE восстанавливает возможно поврежденную таблицу, для определенных механизмов хранения только. По
умолчанию это имеет тот же самый эффект, как myisamchk - восстанавливаются tbl_name.
REPAIR TABLE только применяется к MyISAM, ARCHIVE, и CSV таблицы. См. Раздел
14.3," MyISAM Механизм хранения", и Раздел
14.6," ARCHIVE Механизм хранения", и Раздел
14.5," CSV Механизм хранения"
Этот оператор требует SELECT и
INSERT полномочия для таблицы.
REPAIR
TABLE поддерживается для разделенных таблиц. Однако, USE_FRM опция не
может использоваться с этим оператором на разделенной таблице.
В MySQL 5.7.1, gtid_next должен быть установлен в AUTOMATIC прежде,
чем сделать это заявление. Это ограничение не применяется в MySQL 5.7.2 или позже. (Ошибка #16062608, Ошибка
#16715809, Ошибка #69045)
Можно использовать ALTER TABLE ... REPAIR PARTITION восстановить один или более
разделов; для получения дополнительной информации см. Раздел 13.1.6,"ALTER TABLE Синтаксис", и Раздел
17.3.4, "Обслуживание Разделов".
Хотя обычно Вам никогда не придется работать REPAIR
TABLE, если бедствие ударит, то этот оператор, очень вероятно, возвратит все Ваши данные от a MyISAM таблица. Если Ваши таблицы становятся поврежденными часто, попытайтесь найти
причину этого, избавить от необходимости использовать REPAIR TABLE. См. Раздел
C.5.4.2, "Что к MySQL Do If Продолжает Отказывать", и Раздел
14.3.4,"MyISAM Табличные проблемы".
Сделайте резервное копирование таблицы прежде, чем выполнить табличную работу восстановления; при некоторых обстоятельствах работа могла бы вызвать потерю данных. Возможные причины включают, но не ограничиваются ошибками файловой системы. См. Главу 7, Резервное копирование и Восстановление.
Если сервер отказывает во время a REPAIR
TABLE работа, это важно после перезапуска этого, что Вы сразу выполняете другого REPAIR TABLE оператор для таблицы прежде, чем выполнить любые другие операции
на этом. В худшем случае у Вас мог бы быть новый чистый индексный файл без информации о файле данных, и
затем следующая работа, которую Вы выполняете, могла перезаписать файл данных. Это - маловероятный, но
возможный сценарий, который подчеркивает значение создания резервного копирования сначала.
REPAIR
TABLE возвращает набор результатов со следующими столбцами.
| Столбец | Значение |
|---|---|
Table |
Имя таблицы |
Op |
Всегда repair |
Msg_type |
status, error, info, note, илиwarning |
Msg_text |
Информационное сообщение |
REPAIR
TABLE оператор мог бы произвести много строк информации для каждой восстановленной таблицы. У
последней строки есть a Msg_type значение status и
Msg_test обычно должен быть OK. Если Вы не добираетесь
OK для a MyISAM таблица, следует попытаться
восстановить это с myisamchk
- безопасный - восстанавливаются. (REPAIR TABLE не реализует все опции myisamchk.) С myisamchk - безопасный - восстанавливаются, можно также
использовать опции это REPAIR TABLE не
поддерживает, такой как --max-record-length.
Если Вы используете QUICK опция, REPAIR TABLE попытки восстановить только индексный файл, а не файл данных. Этот
тип восстановления походит, сделанное myisamchk - восстанавливается - быстрый.
Если Вы используете EXTENDED опция, MySQL создает индексировать строку строкой
вместо того, чтобы создать, каждый индексирует за один раз с сортировкой. Этот тип восстановления походит,
сделанное myisamchk
- безопасный - восстанавливается.
USE_FRM опция доступна для использования если .MYI
индексный файл отсутствует или если его заголовок повреждается. Эта опция говорит MySQL не доверять информации
.MYI заголовок файла и воссоздать это использующий информацию от .frm файл. Этот вид восстановления не может быть сделан с myisamchk.
Используйте USE_FRM опция, только если
невозможно использовать регулярный REPAIR режимы! Сообщение сервера
проигнорировать .MYI файл делает важные табличные метаданные сохраненными в
.MYI недоступный к процессу восстановления, у которого могут быть вредные
последствия:
Ток AUTO_INCREMENT значение теряется.
Ссылка к удаленным записям в таблице теряется, что означает, что свободное пространство для удаленных записей останется незанятым после того.
.MYI заголовок указывает, сжимается ли таблица.
Если сервер игнорирует эту информацию, он не может сказать, что таблица сжимается, и восстановление
может вызвать изменение или потерю табличного содержания. Это означает это USE_FRM
не должен использоваться со сжатыми таблицами. Это не должно быть необходимо, так или иначе: Сжатые
таблицы только для чтения, таким образом, они не должны стать поврежденными.
Если Вы используете USE_FRM для таблицы, которая была составлена
различной версией сервера MySQL чем тот, который Вы являетесь в настоящий момент рабочими, REPAIR TABLE не будет пытаться восстановить таблицу. В этом случае, набор
результатов, возвращенный REPAIR TABLE
содержит строку с a Msg_type значение error и a
Msg_text значение Failed repairing incompatible .FRM
file.
Если USE_FRM не используется, REPAIR TABLE проверяет таблицу, чтобы видеть, требуется ли обновление. Если так,
это выполняет обновление, после тех же самых правил как CHECK TABLE ... FOR UPGRADE. См. Раздел
13.7.2.2,"CHECK TABLE Синтаксис", для получения дополнительной
информации. REPAIR TABLE без USE_FRM обновления .frm файл к текущей версии.
По умолчанию, записи сервера REPAIR TABLE
операторы к двоичному журналу так, чтобы они тиражировались к ведомым устройствам репликации. Чтобы подавить
журналирование, определите дополнительное NO_WRITE_TO_BINLOG ключевое слово или его
псевдоним LOCAL.
Когда таблица на ведущем устройстве становится поврежденной, и Вы работаете REPAIR TABLE на этом любые получающиеся изменения к исходной таблице не распространяются к ведомым устройствам.
Можно быть в состоянии увеличиться REPAIR
TABLE производительность, устанавливая определенные системные переменные. См. Раздел
8.6.3, "Скорость REPAIR TABLE Операторы".
REPAIR
TABLE таблица ловит и бросает любые ошибки, которые происходят, копируя табличную статистику от
старого поврежденного файла до недавно создаваемого файла. Например. если идентификатор пользователя владельца
.frm, .MYD, или .MYI
файл отличается от идентификатора пользователя процесса mysqld, REPAIR TABLE генерирует, "не может изменить владение файла" ошибка,
если mysqld
не запускается root пользователь.