PHP5

Иногда в случае каких-либо очень специфических проблем помогает отладка MySQL. Для этого необходимо сконфигурировать сборку MySQL с параметрами --with-debug или --with-debug=full. Чтобы проверить, был ли код MySQL скомпилирован с возможностью отладки, нужно запустить команду: mysqld --help. Если среди опций присутствует флаг --debug, то отладка доступна. Кроме того, если задана возможность отладки, команда mysqladmin ver выводит версию mysqld как mysql ... --debug.

При использовании компиляторов gcc или egcs рекомендуется следующая конфигурационная строка:

CC=gcc CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors \
   -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \
   --with-debug --with-extra-charsets=complex

Такая запись позволит избежать проблем с библиотекой libstdc++ и исключениями C++ (многие компиляторы имеют проблемы с исключениями C++ в кодах потоков) и скомпилировать версию MySQL с поддержкой всех кодировок.

Если есть подозрение, что может возникнуть ошибка переполнения памяти, то можно сконфигурировать MySQL с параметром --with-debug=full, чтобы установить программу контроля выделения памяти (SAFEMALLOC). Однако SAFEMALLOC замедляет работу системы, поэтому при возникновении проблем с производительностью необходимо запустить mysqld с опцией --skip-safemalloc. Эта опция заблокирует проверки переполнения памяти для каждого вызова malloc и free.

Если mysqld перестает падать в аварийном режиме при компиляции ее с параметром --with-debug, то, возможно, вы нашли ошибку в компиляторе или произошла ошибка синхронизации внутри MySQL. В этом случае можно попытаться добавить к переменным CFLAGS и CXXFLAGS в приведенной выше конфигурационной строке -g и не использовать параметр --with-debug. Если mysqld и после этого будет падать, то можно по меньшей мере подключить к ней отладчик gdb или использовать gdb для core-файла, чтобы выяснить, что происходит.

Если MySQL сконфигурирован для отладки, то автоматически становятся доступными множество дополнительных функций контроля надежности, которые отслеживают состояние mysqld. Если они обнаруживают что-либо "неожиданное", то информация об этом будет записана в поток вывода stderr, который safe_mysqld направит в журнал ошибок! Таким образом, если возникают какие-либо неожиданные проблемы с MySQL и при этом доступен исходный код дистрибутива, то первое, что необходимо сделать, - сконфигурировать MySQL для отладки! (А второе необходимое действие - это, конечно, послать письмо на <mysql@lists.mysql.com> и попросить помощи). Пожалуйста, для всех сообщений о сбоях или вопросов относительно используемой версии MySQL используйте скрипт mysqlbug!

В поставке MySQL для Windows файл mysqld.exe по умолчанию скомпилирован с поддержкой трассировочных файлов.

Если сервер mysqld не запускается или если вы можете вызвать его скорую аварийную остановку, то для выяснения причин неполадок можно попытаться создать трассировочный файл.

Для этого необходимо иметь mysqld, скомпилированный для отладки. Проверить, скомпилирован ли mysqld для отладки можно, выполнив mysqld -V. Если номер данной версии заканчивается на -debug, то она скомпилирована с поддержкой трассировочных файлов.

Запустите сервер mysqld с журналом трассировки в каталоге /tmp/mysqld.trace (или C:\mysqld.trace под Windows):

mysqld --debug

Под Windows необходимо также использовать флаг --standalone, чтобы mysqld не стартовал как сервис:

В окне DOS введите следующее:

mysqld --debug --standalone

После этого можно использовать клиента командной строки mysql.exe во втором окне DOS, чтобы воспроизвести проблему. Для остановки описанного выше сервера mysqld следует воспользоваться командой mysqladmin shutdown.

Следует учесть, что трассировочный файл получится очень большим! Чтобы получить трассировочный файл меньшего размера, можно использовать что-нибудь вроде:

mysqld --debug=d,info,error,query,general,where:O,/tmp/mysqld.trace

при этом в каталог /tmp/mysqld.trace будет выводиться только информация с наиболее интересными для вас признаками.

Если вы создаете отчет о подобных ошибках, то, пожалуйста, присылайте в соответствующий список рассылки только те строки из трассировочного файла, которые, по вашему мнению, имеют непосредственное отношение к ошибке! Те же, кто затрудняются определить место ошибки, могут загрузить на ftp трассировочный файл вместе с отчетом об ошибках по адресу ftp://support.mysql.com/pub/mysql/secret/, чтобы разработчики MySQL могли взглянуть на него.

Трассировочный файл создается с помощью пакета DBUG, автором которого является Фред Фиш (Fred Fish). See Раздел E.3, «Пакет DBUG».

В большинстве операционных систем можно запускать mysqld под отладчиком gdb - это позволяет получить больше информации при аварийных остановках mysqld,

С некоторыми более старыми версиями gdb под Linux, чтобы обеспечить возможность отладки потоков mysqld, необходимо использовать run --one-thread. В этом случае в каждый момент времени доступен для отладки только один поток. Нам остается только рекомендовать вам как можно быстрее заменить старые версии отладчика на версию gdb 5.1, поскольку отладка потоков в этой версии работает намного лучше!

При работе mysqld под отладчиком gdb необходимо заблокировать трассировку стеков при помощи --skip-stack-trace, что обеспечит возможность выявить ошибки сегмантацию внутри gdb.

Если постоянно подсоединяются новые пользователи, то отладка MySQL под gdb может оказаться достаточно сложным делом, поскольку gdb не освобождает память, занимаемую старыми потоками. Эту проблему можно устранить, запустив mysqld с параметрами -O thread_cache_size='max_connections+1'. В большинстве случаев даже простое использование -O thread_cache_size=5 может очень помочь!

Для получения дампа оперативной памяти под Linux, если mysqld падает по сигналу SIGSEGV, можно запустить mysqld с опцией --core-file. Этот файл оперативной памяти (core) можно использовать для обратной трассировки при выявлении причин останова mysqld:

shell> gdb mysqld core
gdb> backtrace full
gdb> exit

See Раздел A.4.1, «Что делать, если работа MySQL сопровождается постоянными сбоями».

При использовании версии gdb 4.17.x или выше под Linux необходимо установить в текущем каталоге файл .gdb со следующей информацией:

set print sevenbit off
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
handle SIGWAITING nostop noprint
handle SIGLWP nostop noprint
handle SIGPIPE nostop
handle SIGALRM nostop
handle SIGHUP nostop
handle SIGTERM nostop noprint

Если при отладке потоков с помощью gdb возникают проблемы, необходимо загрузить версию gdb 5.x и попробовать использовать ее вместо прежней. Новая версия отладчика gdb обеспечивает значительно улучшенную обработку потоков!

Ниже приводится пример отладки mysqld:

shell> gdb /usr/local/libexec/mysqld
gdb> run
...
backtrace full # Делайте это при аварийной остановке mysqld

Включите полученный вывод в письмо, сгенерированное с помощью mysqlbug, и пошлите это письмо по адресу <mysql@lists.mysql.com>.

Если mysqld зависает, можно попробовать использовать некоторые системные средства наподобие strace или /usr/proc/bin/pstack для выяснения, где именно произошло зависание mysqld.

strace /tmp/log libexec/mysqld

Если используется интерфейс Perl DBI, то можно получить отладочную информацию, используя метод trace или установив переменную окружения DBI_TRACE. See Раздел 8.2.2, «Интерфейс DBI».

В некоторых операционных системах журнал ошибок в случае смерти mysqld будет содержать трассировку стека. Эти данные можно использовать для выяснения, где (и, может быть, почему) умер mysqld (see Раздел 4.9.1, «Журнал ошибок»). Для получения трассировки стека не следует компилировать mysqld с опцией -fomit-frame-pointer для gcc (see Раздел E.1.1, «Компиляция MySQL для отладки»).

Если файл ошибок содержит что-нибудь похожее на следующее:

mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died
Attemping backtrace. You can use the following information to find out
where mysqld died.  If you see no messages after this, something went
terribly wrong
stack range sanity check, ok, backtrace follows
0x40077552
0x81281a0
0x8128f47
0x8127be0
0x8127995
0x8104947
0x80ff28f
0x810131b
0x80ee4bc
0x80c3c91
0x80c6b43
0x80c1fd9
0x80c1686

то можно определить, где произошла остановка mysqld. Для этого нужно выполнить следующие действия:

Обратите внимание: перед запуском mysqld с --log необходимо проверить все используемые таблицы с помощью myisamchk (see Глава 4, Администрирование баз данных).

Если демон mysqld умрет или зависнет, следует запустить mysqld с опцией --log. Если аварийное завершение mysqld снова повторится, то можно исследовать часть журнала, относящуюся к запросу, убившему mysqld.

При использовании опции --log без имени файла данный журнал хранится в каталоге базе данных как `hostname`.log. В большинстве случаев именно последний запрос в системном журнале приводит к смерти mysqld, но при возможности лучше в этом убедиться: перезапустите mysqld и выполните найденный запрос из командной строки mysql. Если запрос выполняется, то следует протестировать все сложные запросы, которые не завершились.

Можно также попробовать выполнить команду EXPLAIN для всех выражений SELECT, которые занимают длительное время, чтобы убедиться, что mysqld правильно использует индексы. See Раздел 5.2.1, «Синтаксис оператора EXPLAIN (получение информации о SELECT)».

Запросы, требующие слишком длительного времени для выполнения, можно выявить, запустив mysqld с параметром --log-slow-queries. See Раздел 4.9.5, «Журнал медленных запросов».

Если в журнале ошибок (обычно он имеет имя `hostname`.err) присутствует запись "mysqld restarted", то у вас есть шанс найти запрос, вызывающий смерть mysqld. В этом случае необходимо проверить все таблицы с помощью команды myisamchk (see Глава 4, Администрирование баз данных) и проанализировать запросы в журналах MySQL, чтобы определить, какой из них не работает. Если такой запрос найден, прежде всего необходимо попытаться сделать апгрейд MySQL до новейшей версии. Если же это не помогает и нет ничего похожего в архиве списка рассылки mysql, пришлите отчет о данном сбое по адресу <mysql@lists.mysql.com>. Ссылки на архивы списка рассылки доступны по адресу http://lists.mysql.com/.

Если демон mysqld был запущен с параметром myisam-recover, то MySQL автоматически проверяет и пытается восстановить таблицы MyISAM (если они отмечены как "таблица не закрыта правильно" или "таблица повреждена"). В этом случае MySQL запишет в файл hostname.err предупреждение: "Warning: Checking table ...", за которым следует "Warning: Repairing table", если данную таблицу следует исправить. Если таких ошибок в журнале много, а mysqld перед этим не умирал со сбоем, то что-то работает неправильно и необходимы дальнейшие исследования. See Раздел 4.1.1, «Параметры командной строки mysqld».

Конечно, неожиданная смерть mysqld - событие малоприятное, но в этом случае следует не изучать сообщения "Checking table...", а попытаться найти причины остановки mysqld.

Когда таблицы оказываются поврежденными или mysqld всегда дает сбой после некоторых команд, то можно провести испытания (если данный сбой воспроизводим). Для этого нужно выполнить следующие действия:

Для локализации проблемы можно также использовать скрипт mysql_find_rows, чтобы просто выполнить ряд обновляющих команд.