1.7. Как Сообщить об Ошибках или проблемах

Прежде, чем отправить отчет об ошибках о проблеме, пожалуйста, попытайтесь проверить, что это - ошибка и что об этом уже не сообщили:

Запустите, ища MySQL онлайновое руководство в http://dev.mysql.com/doc/. Мы пытаемся усовершенствовать руководство, обновляя это часто с решениями недавно найденных проблем. Кроме того, информация о версии, сопровождающая руководство, может быть особенно полезной, так как довольно возможно, что более новая версия содержит решение Вашей проблемы. Информация о версии доступна в расположении, только данном для руководства.
Если Вы получаете ошибку синтаксического анализа для SQL-оператора, пожалуйста, проверьте свой синтаксис близко. Если невозможно найти что-то не так с этим, чрезвычайно вероятно, что Ваша текущая версия MySQL Server не поддерживает синтаксис, который Вы используете. Если Вы используете текущую версию, и руководство не касается синтаксиса, который Вы используете, MySQL Server не поддерживает Ваш оператор.

Если руководство касается синтаксиса, Вы используете, но у Вас есть более старая версия MySQL Server, следует проверить историю изменений MySQL, чтобы видеть, когда синтаксис был реализован. В этом случае у Вас есть опция обновления до более новой версии MySQL Server.
Для решений некоторых типичных проблем см. Раздел C.5, "Проблемы и Распространенные ошибки".
Ищите базу данных ошибок в http://bugs.mysql.com/, чтобы видеть, сообщили ли об ошибке и фиксирована.
Ищите архивы списка рассылки MySQL в http://lists.mysql.com/. См. Раздел 1.6.1, "MySQL Mailing Lists".
Можно также использовать http://www.mysql.com/search/, чтобы искать все Веб-страницы (включая руководство), которые располагаются в MySQL Web site.

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

Нормальный способ сообщить об ошибках состоит в том, чтобы посетить http://bugs.mysql.com/, который является адресом для нашей базы данных ошибок. Эта база данных общедоступна и может быть просмотрена и искаться любым. Если Вы входите в систему к системе, можно ввести новые отчеты.

Ошибки, отправленные в базе данных ошибок в http://bugs.mysql.com/, которые исправляются для данного выпуска, отмечаются в информации о версии.

Если Вы находите чувствительную ошибку безопасности в MySQL Server, пожалуйста, сообщите нам сразу, отправляя электронное письмо <secalert_us@oracle.com>. Исключение: клиенты Поддержки должны сообщить обо всех проблемах, включая ошибки безопасности, к Поддержке Oracle в http://support.oracle.com/.

Чтобы обсудить проблемы с другими пользователями, можно использовать один из списков рассылки MySQL. Раздел 1.6.1, "MySQL Mailing Lists".

Запись хорошего отчета об ошибках берет терпение, но выполнение этого исправляются, первый раз экономит время и для нас и для вас непосредственно. Хороший отчет об ошибках, содержа полный прецедент для ошибки, делает это очень вероятно, что мы исправим ошибку в следующем выпуске. Этот раздел помогает Вам написать свой отчёт правильно так, чтобы Вы не потратили впустую свои вещи выполнения времени, которые, возможно, не помогают нам очень или вообще. Пожалуйста, считайте этот раздел тщательно и удостоверьтесь, что вся информация, описанная здесь, включается в Ваш отчет.

Предпочтительно, следует протестировать проблему, используя последнюю версию производства или разработки MySQL Server перед регистрацией. Любой должен быть в состоянии повторить ошибку, только используя mysql test < script_file на Вашем прецеденте или выполняя оболочку или сценарий Perl, который Вы включаете в отчет об ошибках. У любой ошибки, которую мы в состоянии повторить, есть высокий шанс того, чтобы быть фиксированным в следующем выпуске MySQL.

Является самым полезным, когда хорошее описание проблемы включается в отчет об ошибках. Таким образом, дайте хороший пример всего, что Вы сделали, который привел к проблеме, и опишите, в точных деталях, проблема непосредственно. Лучшие отчеты - те, которые включают полный пример, показывающий, как воспроизвести ошибку или проблему. См. MySQL Internals: Портирование на Другие Системы.

Помните, что для нас возможно ответить на отчет, содержащий слишком большую информацию, но не к одному содержащему слишком мало. Люди часто опускают факты, потому что они думают, что знают причину проблемы и предполагают, что некоторые детали не имеют значения. Хороший принцип, чтобы следовать - то, что, если Вы вызываете сомнение об утверждении чего-то, утвердите это. Это быстрее и менее неприятно, чтобы записать пару большего количества строк в Вашем отчете чем ожидать дольше ответа, если мы должны попросить, чтобы Вы предоставили информацию, которая отсутствовала в первоначальном сообщении.

Наиболее распространенные ошибки, сделанные в отчетах об ошибках, (a) не включая номер версии распределения MySQL, которое Вы используете, и (b), не полностью описывающий платформу, на которой сервер MySQL устанавливается (включая тип платформы и номер версии). Они - очень соответствующие сведения, и в 99 случаях из 100, отчет об ошибках бесполезен без них. Очень часто мы получаем вопросы как, "Почему это не работает на меня?" Затем мы находим, что опция, которую требуют, не была реализована в той версии MySQL, или что ошибка, описанная в отчете, была исправлена в более новых версиях MySQL. Ошибки часто зависимы от платформы. В таких случаях это почти невозможно для нас, чтобы фиксировать что-либо, не зная операционной системы и номера версии платформы.

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

Если программа производит сообщение об ошибке, очень важно включать сообщение в Ваш отчет. Если мы пытаемся искать что-то от архивов, лучше, что сообщение об ошибке, о котором сообщают точно, соответствует тот, который производит программа. (Даже lettercase должен наблюдаться.) Лучше копировать и вставлять все сообщение об ошибке в Ваш отчет. Никогда недопустимо пытаться воспроизвести сообщение из памяти.

Если у Вас есть проблема с Соединителем/ODBC (MyODBC), пожалуйста, попытайтесь генерировать файл трассировки и отправить его с Вашим отчетом. См. Раздел 21.1.8.2, "Как Сообщить о проблемах Соединителя/ODBC или Ошибках".

Если Ваш доклад включает в себя длинные выходные строки запроса от прецедентов, которые Вы выполняете с mysql инструментом командной строки, можно сделать вывод более читаемым при использовании --vertical опция или \G разделитель оператора. EXPLAIN SELECT пример позже в этом разделе демонстрирует использование \G.

Пожалуйста, включайте следующую информацию в свой отчет:

Номер версии распределения MySQL Вы используете (например, MySQL 5.0.19). Можно узнать, какую версию Вы выполняете, выполняясь mysqladmin версия. mysqladmin программа может быть найдена в bin каталог в соответствии с Вашим каталогом установки MySQL.
Производитель и модель машины, на которой Вы испытываете проблему.
Имя операционной системы и версия. Если Вы работаете с Windows, можно обычно завоевывать репутацию и номер версии двойным щелчком Ваш значок My Computer и раскрытие меню "Help/About Windows". Для большинства Подобных Unix операционных систем можно получить эту информацию, выполняя команду uname -a.
Иногда объем памяти (вещественное число и виртуальный) релевантен. Если в сомнении, включайте эти значения.
Если Вы используете исходное распределение программного обеспечения MySQL, включаете имя и номер версии компилятора, который Вы использовали. Если Вы имеете двоичное распределение, включаете имя распределения.
Если проблема происходит во время компиляции, включайте точные сообщения об ошибках и также несколько строк контекста вокруг незаконного кода в файле, где ошибка происходит.
Если бы mysqld умер, то следует также сообщить об операторе, который разрушал mysqld. Можно обычно получать эту информацию, работая mysqld с журналированием запроса, включенным, и затем взгляд в журнале после mysqld катастрофические отказы. См. MySQL Internals: Портирование на Другие Системы.
Если таблица базы данных связывается с проблемой, включайте вывод от SHOW CREATE TABLE db_name.tbl_name оператор в отчете об ошибках. Это - очень легкий способ получить определение любой таблицы в базе данных. Информация помогает нам создать ситуацию, соответствующую тот, который Вы испытали.
Режим SQL в действительности, когда проблема произошла, может быть существенным, так, пожалуйста, сообщите о значении sql_mode системная переменная. Для хранимой процедуры, сохраненной функции, и триггерных объектов, соответствующего sql_mode значение является тем в действительности, когда объект создавался. Для хранимой процедуры или функции, SHOW CREATE PROCEDURE или SHOW CREATE FUNCTION оператор показывает соответствующий режим SQL, или можно запросить INFORMATION_SCHEMA для информации:
```
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODEFROM INFORMATION_SCHEMA.ROUTINES;
```
Для триггеров можно использовать этот оператор:
```
SELECT EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE, TRIGGER_NAME, SQL_MODEFROM INFORMATION_SCHEMA.TRIGGERS;
```
Для связанных с производительностью ошибок или проблем с SELECT операторы, следует всегда включать вывод EXPLAIN SELECT ..., и по крайней мере число строк, что SELECT оператор производит. Следует также включать вывод от SHOW CREATE TABLE tbl_name для каждой таблицы, которая включается. Чем больше информации, которую Вы предоставляете о своей ситуации, тем более вероятно случается так, что кто-то может помочь Вам.

Следующее является примером очень хорошего отчета об ошибках. Операторы выполняются, используя mysql инструмент командной строки. Отметьте использование \G разделитель оператора для операторов, которые иначе обеспечивали бы очень долго выходные строки, которые трудно считать.
```
mysql> SHOW VARIABLES;mysql> SHOW COLUMNS FROM ...\G       <output from SHOW COLUMNS>mysql> EXPLAIN SELECT ...\G       <output from EXPLAIN>mysql> FLUSH STATUS;mysql> SELECT
                    ...;       <A short version of the output from
                    SELECT, including the time taken to run the query>mysql> SHOW STATUS;       <output
                    from SHOW STATUS>
```
Если ошибка или проблема происходят, работая mysqld, попытайтесь обеспечить входной сценарий, который воспроизводит аномалию. Этот сценарий должен включать любые необходимые исходные файлы. Чем более близко сценарий может воспроизвести Вашу ситуацию, тем лучше. Если можно сделать восстанавливаемый прецедент, следует загрузить его, чтобы быть присоединенными к отчету об ошибках.

Если невозможно обеспечить сценарий, следует, по крайней мере, включать вывод от mysqladmin расширенного состояния переменных processlist в Вашем отчете предоставить некоторую информацию о том, как Ваша система выполняет.
Если невозможно произвести прецедент только с несколькими строками, или если тестовая таблица является слишком большой, чтобы быть включенной в отчет об ошибках (больше чем 10 строк), следует вывести свои таблицы, используя mysqldump и создать a README файл, который описывает Вашу проблему. Создайте сжатый архив своих файлов, используя tar и gzip или zip. После того, как Вы инициируете отчет об ошибках для нашей базы данных ошибок в http://bugs.mysql.com/, щелкните по вкладке Files в отчете об ошибках для инструкций по загрузке архива к базе данных ошибок.
Если Вы полагаете, что сервер MySQL производит странное следствие оператора, включайте не только результат, но также и Ваше мнение о том, чем результат должен быть, и объяснение, описывающее основание для Вашего мнения.
Когда Вы обеспечиваете пример проблемы, лучше использовать имена таблиц, имена переменной, и т.д которые существуют в Вашей фактической ситуации чем придумать новые имена. Проблема могла быть связана с именем таблицы или переменной. Эти случаи редки, возможно, но лучше быть безопасным чем жаль. В конце концов для Вас должно быть легче обеспечить пример, который использует Вашу фактическую ситуацию, и это во что бы то ни стало лучше для нас. Если у Вас есть данные, что Вы не хотите быть видимыми другим в отчете об ошибках, можно загрузить это использующий вкладку Files как ранее описано. Если информация действительно совершенно секретна, и Вы не хотите показывать это даже нам, идти вперед и обеспечивать пример, используя другие имена, но, пожалуйста, расцените это как последний выбор.
Включайте все опции, данные соответствующим программам, если возможный. Например, укажите на опции, которые Вы используете, когда Вы запускаете mysqld сервер, так же как опции, которые Вы используете, чтобы выполнить любые клиентские программы MySQL. Опции к программам, таким как mysqld и mysql, и к сконфигурировать сценарию, являются часто ключевыми к разрешению проблем и являются очень релевантными. Это никогда не плохая идея включать их. Если Ваша проблема включает программу, записанную в язык, такой как Perl или PHP, пожалуйста, включайте номер версии языкового процессора, так же как версию для любых модулей, которые использует программа. Например, если у Вас есть сценарий Perl, который использует DBI и DBD::mysql модули, включайте номера версий для Perl, DBI, и DBD::mysql.
Если Ваш вопрос связывается с системой полномочия, пожалуйста, включайте вывод mysqlaccess, вывод перезагрузки mysqladmin, и все сообщения об ошибках, которые Вы получаете, пытаясь соединиться. Когда Вы тестируете свои полномочия, Вы должны первый показ mysqlaccess. После этого выполните версию перезагрузки mysqladmin и попытайтесь соединиться с программой, которая дает Вам проблему. mysqlaccess может быть найден в bin каталог в соответствии с Вашим каталогом установки MySQL.
Если у Вас есть патч для ошибки, включайте это. Но не предполагайте, что патч - все, в чем мы нуждаемся, или что мы можем использовать его, если Вы не предоставляете некоторую необходимую информацию, такую как прецеденты, показывая ошибку что Ваши исправления патча. Мы могли бы найти проблемы с Вашим патчем, или мы не могли бы понять это вообще. Если так, мы не можем использовать это.

Если мы не можем проверить точную цель патча, мы не будем использовать это. Прецеденты помогают нам здесь. Покажите, что патч обрабатывает все ситуации, которые могут произойти. Если мы находим промежуточный случай (даже редкий), где патч не будет работать, это может быть бесполезно.
Предположения о том, какова ошибка, почему происходит, или от чего это зависит, являются обычно неправильными. Даже команда MySQL не может предположить такие вещи без первого использования отладчика, чтобы определить реальную причину ошибки.
Укажите в своем отчете об ошибках, что Вы проверили справочник и почтовый архив так, чтобы другие знали, что Вы попытались решить проблему самостоятельно.
Если Ваши данные кажутся поврежденными, или Вы получаете ошибки, когда Вы получаете доступ к определенной таблице, сначала проверьте свои таблицы с CHECK TABLE. Если тот оператор сообщает о каких-либо ошибках:
- InnoDB механизм восстановления катастрофического отказа обрабатывает уборку, когда сервер перезапускается, будучи уничтоженным, таким образом, в типичной работе нет никакой потребности "восстановить" таблицы. Если Вы встречаетесь с ошибкой с InnoDB таблицы, перезапустите сервер и видьте, сохраняется ли проблема, или ли ошибка только кэшированные данные, на которые влияют, в памяти. Если данные повреждаются на диске, рассмотрите перезапуск с innodb_force_recovery опция, включенная так, чтобы можно было вывести таблицы, на которые влияют.
- Для нетранзакционных таблиц попытайтесь восстановить их с REPAIR TABLE или с myisamchk. См. Главу 5, MySQL Server Administration.
Если Вы запускаете Windows, пожалуйста, проверьте значение lower_case_table_names использование SHOW VARIABLES LIKE 'lower_case_table_names' оператор. Эта переменная влияет, как сервер обрабатывает lettercase имен базы данных и имен таблиц. Его эффект для данного значения должен быть как описан в Разделе 9.2.2, "Чувствительность к регистру Идентификатора".
Если Вы часто получаете поврежденные таблицы, следует попытаться узнать, когда и почему это происходит. В этом случае журнал ошибок в каталоге данных MySQL может содержать некоторую информацию о том, что произошло. (Это - файл с .err суффикс на имя.) См. Раздел 5.2.2, "Журнал ошибок". Пожалуйста, включайте любую релевантную информацию от этого файла в Вашем отчете об ошибках. Обычно mysqld никогда не должен разрушать таблицу, если бы ничто не уничтожило его в середине обновления. Если можно найти причину смерти mysqld, для нас намного легче предоставить Вам фиксацию для проблемы. См. Раздел C.5.1, "Как Определить то, Что Вызывает проблему".
Если возможный, загрузка и установка новая версия MySQL Server и проверяет, решает ли это Вашу проблему. Все версии программного обеспечения MySQL, полностью протестированного и, должны работать без проблем. Мы верим в создание всего настолько обратно совместимого насколько возможно, и следует быть в состоянии переключить версии MySQL без труда. См. Раздел 2.1.2, "Выбирая Распределение MySQL Which, чтобы Установить".