П О Р Т А Л                            
С Е Т Е В Ы Х                          
П Р О Е К Т О В                        
  
Поиск по сайту:
                                                 
Главная

О проекте

Web-мастеру
     HTML & JavaScript
     SSI
     Perl
     PHP
     XML & XSLT
     Unix Shell

MySQL

Безопасность

Хостинг

Другое








Самое читаемое:

Учебник PHP - "Для Чайника".
Просмотров 179492 раз(а).

Иллюстрированный самоучитель по созданию сайтов.
Просмотров 77404 раз(а).

Учебник HTML.
Просмотров 75098 раз(а).

Руководство по PHP5.
Просмотров 46129 раз(а).

Хостинг через призму DNS.
Просмотров 53364 раз(а).

Подборка текстов стандартных документов.
Просмотров 46120 раз(а).

Учебник PHP - Самоучитель
Просмотров 52278 раз(а).

Документация на MySQL (учебник & справочное руководство)
Просмотров 52828 раз(а).

Внешние атаки...
Просмотров 42752 раз(а).

Учебник PHP.
Просмотров 38260 раз(а).

SSI в примерах.
Просмотров 28374 раз(а).



 
 
| Добавить в избранное | Сделать стартовой | Помощь





Приложение E. Перенос на другие системы
Пред.     След.

E.1. Отладка сервера MySQL
E.1.4. Использование трассировки стека

В некоторых операционных системах журнал ошибок в случае смерти 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. Для этого нужно выполнить следующие действия:

  1. Скопируйте приведенные выше числовые значения в файл, например mysqld.stack.

  2. Создайте файл символов для сервера mysqld:

    nm -n libexec/mysqld > /tmp/mysqld.sym
    

    Следует учесть, что во многих бинарных поставках MySQL приведенный выше файл с именем mysqld.sym.gz уже имеется. В этом случае необходимо распаковать его следующим образом:

    gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym
    
  3. Выполните resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack, чтобы вывести место остановки mysqld. Если и это не поможет определить причину останова mysqld, то следует сделать отчет об ошибке и включить в него данный вывод с комментарием. Следует учитывать, однако, что в большинстве случаев наличие лишь только трассировки стеков не поможет нам определить причину данной проблемы. Чтобы иметь возможность локализовать данный сбой или рекомендовать обходной путь, нам, как правило, необходимо знать, какой именно запрос привел к остановке mysqld и, желательно, иметь контрольный пример, чтобы мы могли воспроизвести данную проблему! See Раздел 1.8.1.3, «Как отправлять отчеты об ошибках или проблемах».


Назад Начало Главы Начало Раздела Вперед

Пред. Глава След. Глава
Приложение D. История изменений и обновлений MySQL Начало Книги Приложение F. Переменные окружения


Если Вы не нашли что искали, то рекомендую воспользоваться поиском по сайту:
 





Copyright © 2005-2016 Project.Net.Ru