C.5.4.2. Что к Do If MySQL Продолжает Отказывать

Каждая версия MySQL тестируется на многих платформах прежде, чем она будет выпущена. Это не означает, что нет никаких ошибок в MySQL, но если есть ошибки, они должны быть очень немногими и могут быть тверды найти. Если у Вас есть проблема, всегда помогает, пытаетесь ли Вы узнать точно, что разрушает Вашу систему, потому что у Вас есть намного лучший шанс получения проблемы, решенной быстро.

Во-первых, следует попытаться узнать, является ли проблема, что mysqld сервер умирает или имеет ли Ваша проблема отношение к Вашему клиенту. Можно проверить, сколько времени Ваш mysqld сервер произошел, выполняясь mysqladmin версия. Если mysqld умер и перезапустил, можно найти причину, смотря в журнале ошибок сервера. См. Раздел 5.2.2, "Журнал ошибок".

На некоторых системах можно найти в журнале ошибок трассировку стека того, где mysqld умер, который можно разрешить с resolve_stack_dump программа. См. MySQL Internals: Портирование на Другие Системы. Отметьте, что значения переменных, записанные в журнале ошибок, возможно, всегда не на 100 % корректны.

Много катастрофических отказов сервера вызываются поврежденными файлами данных или индексными файлами. MySQL обновляет файлы на диске с write() системный вызов после каждого SQL-оператора и перед клиентом уведомляется о результате. (Это не истина, если Вы работаете с --delay-key-write, когда файлы данных пишутся, но не индексные файлы.) Это означает, что содержание файла данных безопасно, даже если mysqld отказывает, потому что операционная система гарантирует, что несброшенные данные пишутся диску. Можно вынудить MySQL сбросить все к диску после каждого SQL-оператора, запускаясь mysqld с --flush опция.

Предыдущие средства, что обычно недопустимо получить поврежденные таблицы, если одно из следующего не происходит:

Сервер MySQL или узел сервера были уничтожены в середине обновления.
Вы нашли ошибку в mysqld, который заставил ее умирать в середине обновления.
Некоторая внешняя программа управляет файлами данных или индексными файлами одновременно как mysqld, не блокируя таблицу должным образом.
Вы выполняете много mysqld серверов, используя тот же самый каталог данных на системе, которая не поддерживает хорошие блокировки файловой системы (обычно обрабатываемый lockd менеджер блокировок), или Вы выполняете многократные серверы с внешней отключенной блокировкой.
У Вас есть разрушенный файл данных или индексный файл, который содержит очень поврежденные данные, которые перепутали mysqld.
Вы нашли ошибку в коде хранения данных. Это не вероятно, но это, по крайней мере, возможно. В этом случае можно попытаться изменить механизм хранения на другой механизм при использовании ALTER TABLE на восстановленной копии таблицы.

Поскольку очень трудно знать, почему что-то отказывает, сначала попытайтесь проверить, ли вещи, которые работают на катастрофический отказ других для Вас. Попробуйте следующие вещи:

Остановите mysqld сервер с mysqladmin завершением работы, работайте, myisamchk - тихий - вынуждают */*.MYI из каталога данных проверить все MyISAM таблицы, и перезапуск mysqld. Это гарантирует, что Вы работаете от чистого состояния. См. Главу 5, MySQL Server Administration.
Запустите mysqld с общего включенного журнала запросов (см. Раздел 5.2.3, "Общий Журнал запросов"). Затем попытайтесь определить от информации, записанной журналу, уничтожает ли некоторый определенный запрос сервер. Приблизительно 95 % всех ошибок связываются с определенным запросом. Обычно, это - один из последних запросов в файле журнала как раз перед перезапусками сервера. См. Раздел 5.2.3, "Общий Журнал запросов". Если можно неоднократно уничтожать MySQL с определенным запросом, даже когда Вы проверили все таблицы прежде, чем выпустить его, то изолировали ошибку и следует представить отчет об ошибках для нее. См. Раздел 1.7, "Как Сообщить об Ошибках или проблемах".
Попытайтесь сделать прецедент, который мы можем использовать, чтобы повторить проблему. См. MySQL Internals: Портирование на Другие Системы.
Попытайтесь выполнить тесты в mysql-test каталог и сравнительные тесты MySQL. См. Раздел 22.1.2, "MySQL Test Suite". Они тестируют MySQL скорее хорошо. Можно также добавить код к сравнительным тестам, который моделирует Ваше приложение. Сравнительные тесты находятся в sql-bench каталог в исходном распределении или, для двоичного распределения, в sql-bench каталог в соответствии с Вашим каталогом установки MySQL.
Попробуйте fork_big.pl сценарий. (Это располагается в tests каталог исходных дистрибутивов.)
Конфигурирование MySQL для того, чтобы отладить делает намного легче собрать информацию о возможных ошибках, если что-то идет не так, как надо. Реконфигурируйте MySQL с -DWITH_DEBUG=1 опция к CMake и затем перекомпилировала. См. MySQL Internals: Портирование на Другие Системы.
Удостоверьтесь, что Вы применили последние патчи для своей операционной системы.
Используйте --skip-external-locking опция к mysqld. На некоторых системах, lockd менеджер блокировок не работает должным образом; --skip-external-locking опция говорит mysqld не использовать внешнюю блокировку. (Это означает, что невозможно выполнить два mysqld сервера на том же самом каталоге данных и что следует быть осторожными, если Вы используете myisamchk. Однако, это может быть поучительно, чтобы попробовать опцию как тест.)
Если mysqld, кажется, работает, но не отвечает, попробуйте mysqladmin-u корень processlist. Иногда mysqld не подвешивается даже при том, что это кажется безразличным. Проблема может состоять в том, что все соединения используются, или может быть некоторая внутренняя проблема блокировки. mysqladmin-u корень processlist обычно в состоянии сделать соединение даже в этих случаях, и может обеспечить полезную информацию о текущем числе соединений и их состояния.
Выполните команду mysqladmin-i 5 состояний или mysqladmin-i 5-r состояний в отдельном окне, чтобы произвести статистику, выполняя другие запросы.
Попробуйте следующее:
1. Запустите mysqld с gdb (или другой отладчик). См. MySQL Internals: Портирование на Другие Системы.
2. Выполните свои сценарии тестирования.
3. Напечатайте след и локальные переменные на трех самых низких уровнях. В gdb можно сделать это со следующими командами, когда mysqld отказал внутри gdb:
```
backtraceinfo localupinfo localupinfo local
```
  С gdb можно также исследовать, с которым существуют потоки info threads и переключитесь на определенный поток с thread N, где N ID потока.
Попытайтесь моделировать свое приложение со сценарием Perl, чтобы вынудить MySQL отказать или неправильно себя вести.
Отправьте нормальный отчет об ошибках. См. Раздел 1.7, "Как Сообщить об Ошибках или проблемах". Будьте еще более подробными чем обычно. Поскольку работы MySQL для многих людей, катастрофический отказ мог бы следовать из чего-то, что существует только на Вашем компьютере (например, ошибка, которая связывается с Вашими определенными системными библиотеками).
Если у Вас есть проблема с таблицами, содержащими строки динамически-длиной, и Вы используете только VARCHAR столбцы (нет BLOB или TEXT столбцы), можно попытаться изменить все VARCHAR к CHAR с ALTER TABLE. Это вынуждает MySQL использовать строки фиксированного размера. Строки фиксированного размера берут небольшое дополнительное пространство, но намного более терпимы к повреждению.

Текущий динамический код строки использовался в течение нескольких лет с очень немногими проблемами, но строки динамически-длиной являются по своей природе более склонными к ошибкам, таким образом, это может быть хорошая идея попробовать эту стратегию видеть, помогает ли это.
Рассмотрите возможность аппаратных отказов, диагностируя проблемы. Дефектные аппаратные средства могут быть причиной повреждения данных. Обратите особое внимание на свою память и дисковые подсистемы, диагностируя аппаратные средства.