Spec-Zone .ru
спецификации, руководства, описания, API
|
Следующие общие руководящие принципы применяются к поиску и устранению неисправностей InnoDB
проблемы:
Когда работа перестала работать, или Вы подозреваете ошибку, смотрите на журнал ошибок сервера MySQL (см. Раздел 5.2.2, "Журнал ошибок").
Если отказ связывается с мертвой блокировкой, работайте с
innodb_print_all_deadlocks
опция, включенная так, чтобы детали о каждом InnoDB
мертвая блокировка
печатается к журналу ошибок сервера MySQL.
Проблемы, касающиеся InnoDB
словарь данных включает
отказавший CREATE TABLE
операторы (осиротевшие табличные файлы), неспособность открыться .InnoDB
файлы, и система не могут найти путь определенные ошибки. Для получения
информации об этих видах проблем и ошибок, см. Раздел
14.2.4.7, "Диагностируя InnoDB
Операции Словаря данных".
Диагностируя, обычно лучше выполнить сервер MySQL от командной строки, а не через
mysqld_safe или как служба Windows. Можно тогда
видеть, какие печатные издания mysqld к консоли, и так имеют лучшее схватывание
того, что продолжается. На Windows запустите mysqld с --console
опция, чтобы направить вывод к консоли.
Используйте
InnoDB
Мониторы, чтобы получить информацию о проблеме (см. Раздел
14.2.4.4,"SHOW ENGINE INNODB STATUS
и InnoDB
Мониторы"). Если проблема связана с
производительностью, или Ваш сервер, кажется, подвешивается, использует стандартный Монитор, чтобы
напечатать информацию о внутреннем состоянии InnoDB
. Если проблема с
блокировками, используйте Монитор Блокировки. Если проблема находится в создании таблиц или других
операциях словаря данных, используйте Табличный Монитор, чтобы напечатать содержание InnoDB
внутренний словарь данных. Видеть, что информация о табличной
области использует Монитор Табличной области.
Если Вы подозреваете, что таблица повреждена, выполняется CHECK TABLE
на той таблице.
Поиск и устранение неисправностей ступает для InnoDB
Проблемы ввода-вывода
зависят от того, когда проблема происходит: во время запуска сервера MySQL, или во время нормального
функционирования, когда оператор DML или DDL перестал работать из-за проблем на уровне файловой системы.
Если что-то идет не так, как надо когда InnoDB
попытки инициализировать его
табличную область или его файлы журнала, удалите все файлы, создаваемые InnoDB
:
все ibdata
файлы и все ib_logfile
файлы. Если Вы
уже создали некоторых InnoDB
таблицы, также удалите соответствие .frm
файлы для этих таблиц, и любого .ibd
файлы, если Вы используете многократные табличные области из каталогов базы данных MySQL. Затем попробуйте
InnoDB
создание базы данных снова. Для самого легкого поиска и устранения
неисправностей запустите сервер MySQL с командной строки так, чтобы Вы видели то, что происходит.
Если InnoDB
печатает ошибку операционной системы во время работы файла, обычно
у проблемы есть одно из следующих решений:
Удостоверьтесь InnoDB
каталог файла данных и InnoDB
каталог журнала существует.
Удостоверьтесь, что у mysqld есть права доступа, чтобы создать файлы в тех каталогах.
Удостоверьтесь, что mysqld может считать надлежащее my.cnf
или my.ini
файл опции, так, чтобы
это запустилось с опций, которые Вы определили.
Удостоверьтесь, что диск не полон, и Вы не превышаете выделенного дискового пространства.
Удостоверьтесь, что имена, которые Вы определяете для подкаталогов и файлов данных, не сталкиваются.
Перепроверьте синтаксис innodb_data_home_dir
и innodb_data_file_path
значения. В частности любой MAX
значение в innodb_data_file_path
опция является жестким пределом, и превышением,
которые ограничивают причины фатальная ошибка.