Spec-Zone .ru
спецификации, руководства, описания, API
|
|
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 опция является жестким пределом, и превышением,
которые ограничивают причины фатальная ошибка.