Поиск

Списки рассылки MySQL

Перечень списков рассылки MySQL
Чтобы подписаться или отказаться от подписки на любой список рассылки, упоминаемый в настоящем разделе, зайдите на http://lists.mysql.com. Не посылайте запросов на подписку или отказ от подписки в любой их списков, поскольку такие письма автоматически рассылаются тысячам подписчиков. Ваш локальный сайт может иметь множество подписчиков на списки рассылки MySQL. Если это так, имеет смысл завести локальные списки рассылки, чтобы сообщения, отправленные на lists.mysql.com, рассылались адресатам, занесенным в них. В этом случае обратитесь к системному администратору, чтобы он внес вас в локальный список рассылки MySQL. Если вы желаете, чтобы сообщения из рассылки попадали в отдельный почтовый ящик в вашей почтовой программе, настройте фильтр на базе заголовков сообщений. Для идентификации этих сообщений можно использовать заголовки List-ID: или Delivered-TO:. Ниже представлены списки рассылки MySQL.
  • anounce Это рассылка объявлений о новых версиях MySQL и сопутствующих программ. Это рассылка с малой активностью; на нее должны быть подписаны все пользователи MySQL.
  • mysql Это основная рассылка для общих дискуссий по вопросам MySQL. Стоит заметить, что некоторые темы более подробно обсуждаются в специальных рассылках. Если вы отправите письмо не в ту рассылку, то, вероятно, не получите ответа.
  • mysql-digest Это рассылка mysql в форме дайджеста. Если вы подпишетесь на эту рассылку, то будете ежедневно получать группу сообщений одним письмом.
  • bugs Эта рассылка может быть интересна, если вы хотите быть в курсе сообщений о последней версии MySQL или желаете включиться в процесс поиска и исправления ошибок.
  • bugs-digest Это рассылка bugs в форме дайджеста.
  • internals Эта рассылка предназначена в основном для тех, кто имеет дело с кодом MySQL. Это также форум для дискуссий о разработке MySQL и рассылки исправлений.
  • internals-digest Это рассылка internals в форме дайджеста.
  • mysqldoc Эта рассылка для тех, кто работает над созданием документации MySQL: людей из MySQL AB, переводчиков и других членов сообщества.
  • mysqldoc-digest Это рассылка mysqldoc в форме дайджеста.
  • benchmarks Это рассылка для тех, кого интересуют вопросы производительности. Дискуссии сосредоточены вокруг производительности СУБД (не только MySQL), а также касаются более широких категорий, включая производительность ядра, файловых систем, дисковых систем и так далее.
  • benchmarks-digest Это рассылка benchmarks в форме дайджеста.
  • packagers Это рассылка для дискуссий об объединении в пакеты и распространении MySQL. В данном форуме участвуют те, кто занимается поддержкой распространения для обмена идеями о том, как формировать пакеты MySQL и как добиваться того, чтобы MySQL выглядел и работал насколько возможно единообразно на всех платформах и операционных системах.
  • packagers-digest Это рассылка packagers в форме дайджеста
  • Java Это рассылка для дискуссий, связанных с сервером MySQL и языком Java. В основном здесь обсуждаются JDBC-драйвера, включая MySQL Connector/J.
  • java-digest Это рассылка j ava в форме дайджеста.
  • Win32 Этот список предназначен для обсуждения всего, что касается использования MySQL под управлением операционных систем семейства Microsoft, таких как Windows 9x, Me, NT, 2000 и ХР.
  • win32-digest Это рассылка Win32 в форме дайджеста.
  • myodbc Эта рассылка относится ко всему, что связано с подключением к MySQL через ODBC.
  • myodbc-digest Это рассылка myodbc в форме дайджеста.
  • gui-tools Здесь обсуждаются инструменты MySQL с графическим интерфейсом пользователя, включая MySQL Administrator и графический клиент MySQL Control Center.
  • gui-tools-digest Это рассылка gui-tools в форме дайджеста.
  • plusplus Этот список рассылки касается вопросов программирования на C++ для MySQL.
  • plusplus-digest Это рассылка plusplus в форме дайджеста.
  • msql-mysql-modules Эта рассылка для всех вопросов, связанных с поддержкой MySQL языка Perl, в частности, модулем DBD:mysql.
  • msql-mysql-modules-digest Это рассылка msql-mysql-modules в форме дайджеста. Если вы не можете получить ответ на заданный вопрос в списках рассылки MySQL, выходом может быть заключение договора поддержки с компанией MySQL AB. Это позволит вам напрямую контактировать с разработчиками MySQL (см. раздел Поддержка, предоставляемая компанией MySQL AB). Ниже представлен перечень списков рассылки MySQL на других языках (кроме английского). Эти рассылки компанией MySQL AB не управляются.

  1. mysql-france-subscribe@yahoogroups.com Список рассылки на французском языке.
  2. list@tinc.net

    Список рассылки на корейском языке. Для подписки отправьте по адресу списка сообщение subscribe mysql ваш@почтовый.адрес.

  3. mysql-de-request@lists.4t2.com Список рассылки на немецком языке. Для подписки отправьте по адресу списка сообщение subscribe mysql-de ваш@почтовый.адрес. Дополнительную информацию об этом списке можно найти по адресу http://www.4t2.com/mysql.
  4. mysql-br-request@listas.linkway.com.br
Список рассылки на португальском языке. Для подписки отправьте по адресу списка сообщение subscribe mysql-br ваш@почтовый.адрес. mysql-alta@elistas.net Список рассылки на испанском языке. Для подписки отправьте по адресу списка сообщение subscribe mysql ваш@почтовый.адрес.
Как задавать вопросы и сообщать об ошибках
Прежде чем посылать вопрос или сообщение об ошибке, выполните следующие действия:
  1. Начните с поиска в онлайновом руководстве по MySQL на http://dev.mysql .com/doc/. Мы стараемся поддерживать это руководство в актуальном состоянии, часто об новляя его по мере решения обнаруженных проблем. Полезной может оказаться и хронология изменений (http: //dev.mysql .com/doc/mysql/en/News.html), по скольку весьма вероятно, что в новых версиях та или иная проблема уже решена.
  2. Просмотрите базу данных ошибок, которая доступна по адресу http://bugs.mysql.com/. Возможно, ошибка, о которой вы собираетесь сооб щить, уже обнаружена и исправлена.
  3. Поищите в архиве списков рассылки на http: //lists. mysql. com/.
  4. Воспользуйтесь поисковой службой http://www.mysql.com/search/ для поиска по всему Web-сайту MySQL AB, включая онлайновое руководство.

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

Как сообщать об ошибках и проблемах
Обычное место, куда нужно направля ть сообщения об ошибках, это http://bugs.mysql.com/ - адрес нашей базы данных ошибок. Эта база общедоступна, любой может ее просматривать и выполнять в ней поиск. Если вы зарегистрируетесь в системе, то также сможете вводить в нее новые сообщения. Написание качественного отчета об ошибке требует немалого терпения, однако, составив его правильно, вы сэкономите как свое время, так и наше. Хороший отчет об ошибке должен содержать полное описание пути, приводящего к ее проявлению (случай тестирования); весьма вероятно, что мы исправим обнаруженную вами ошибку уже в очередном выпуске. Сведения, представленные в этом разделе, посвящены тому, как правильно составлять такие отчеты, дабы не пришлось впустую тратить время на то, что либо мало поможет нам, либо вообще не поможет. Для генерации отчета об ошибке (или сообщения о любой проблеме) мы рекомендуем использовать сценарий mysqlbug. Упомянутый сценарий находится в каталоге scripts (исходного дистрибутива) и в каталоге bin (бинарного дистрибутива MySQL). Если запустить mysqlbug не удается (например, если вы работаете в среде Windows), все равно важно включить всю необходимую информацию, указанную в настоящем разделе (и самое главное - описание операционной системы и версии MySQL). Сценарий mysqlbug поможет сгенерировать отчет об ошибке, собрав большую часть информации автоматически, но кое-что важное придется ввести вручную. Внимательно прочтите настоящий раздел и убедитесь, что вся перечисленная здесь информация должным образом отражена в отчете. Прежде всего, необходимо убедиться в наличии проблемы в последней производственной версии MySQL или версии, находящейся на стадии разработки. Любой может воспроизвести найденную ошибку, просто запустив mysql test ; файл_сценария или же запустив Perl-сценарий, включенный в отчет об ошибке. Все ошибки, отправленные в базу ошибок на http://bugs.mysql.com/, будут исправлены или документированы в следующем выпуске MySQL. Если исправление ошибки требует только небольших изменений в коде, возможно, будет разослано только исправление. Если вы обнаружили существенную ошибку в системе безопасности MySQL, сообщение об этом необходимо прислать по адресу security@mysql.com. Если вы подготовили воспроизводимый отчет об ошибке, присылайте его в базу ошибок по адресу http://bugs.mysql.com/. Помните, что даже в этом случае желательно запустить сценарий mysqlbug для сбора информации о вашей системе. Любая ошибка, которую мы сможем воспроизвести, имеет хорошие шансы на то, чтобы быть исправленной в очередном выпуске MySQL. Сообщения о проблемах иного рода можно отправлять в списки рассылки MySQL. Помните, что мы можем ответить на сообщения, содержащие слишком много информации, но не можем ответить на те, что содержат ее слишком мало. Люди часто пропускают некоторые факты, поскольку думают, что имеют представление о причинах проблем, и предполагают, что детали значения не имеют. Хороший принцип, которым следует руководствоваться, может быть сформулирован следующим образом: если вы

сомневаетесь, стоит ли сообщать о чем-то, то сообщайте. Получится гораздо быстрее и проще, если вы напишите кучу дополнительных строк в сообщении, чем если нам придется запрашивать у вас дополнительную информацию, пропущенную в первичном сообщении, и ждать ответа. Наиболее часто встречающиеся ошибки в отчетах таковы: (а) не указан номер версии используемого дистрибутива MySQL и (Ь) не полностью описана платформа, на которой установлен сервер MySQL (включая тип платформы и номер версии). Это чрезвычайно важная информация, и в 99 случаях из 100 сообщение об ошибке без нее бесполезно. Очень часто мы получаем вопросы вроде такого: Почему у меня то-то и то-то не работает? Потом выясняется, что возможность просто в данной версии MySQL не реализована, или же эта ошибка известна и исправлена в более новой версии MySQL. Иногда ошибка оказывается зависимой от платформы и в этом случае мы не в состоянии исправить что-либо, не зная операционной системы и номера ее версии. Если вы скомпилировали MySQL из исходных текстов, не забудьте также указать информацию о компиляторе, если это связано с проблемой. Часто люди сталкиваются с ошибками компиляторов, а думают, что ошибки связаны с кодом MySQL. Большинство компиляторов находятся в постоянном процессе разработки и становятся лучше от версии к версии. Чтобы определить, не вызвана ли проблема компилятором, нам надо знать, какой компилятор вы используете. Помните, что любые проблемы с компиляцией должны рассматриваться как ошибки и сообщаться соответствующим образом. Лучше всего, если в отчет об ошибке включено исчерпывающее описание проблемы. Имеется в виду описание всего того, что вы делали и столкнулись с ошибкой, а также подробное описание самой проблемы. То есть наилучшими отчетами об ошибках являются такие, которые содержат полный пример, показывающий, как воспроизвести описанную ошибку или проблему. Если какая-то программа выдает сообщение об ошибке, очень важно включить это сообщение в отчет. Если мы попытаемся найти что-нибудь в архивах, лучше, чтобы сообщение об ошибке, сгенерированное программой, было точно в том виде, как вы его увидели (важен даже регистр символов). Никогда не пытайтесь воспроизвести по памяти это сообщение, а вместо этого просто скопируйте его и вставьте в отправляемый отчет. Если у вас возникла проблема с Connector/ODBC (MyODBC), пожалуйста, попытайтесь сгенерировать трассировочный файл MyODBC и прислать его вместе с отчетом. Помните, что многие люди, которые будут читать ваш отчет об ошибке, используют отображение с шириной 80 символов. Поэтому при генерации сообщения об ошибке с помощью mysqlbug применяйте опцию -vertical (или символ завершения операторов G) для вывода, который может по ширине превысить общепринятые размеры (например, с оператором explain SELECT, как показано выше в примере). В отправляемый отчет должна быть включена следующая информация:

  1. Номер версии используемого дистрибутива MySQL, например, MySQL 4.0.12. Эту информацию можно получить, запустив mysqladmin version. Программа mysqladmin расположена в подкаталоге bin каталога с инсталляцией MySQL.
  2. Производитель и модель компьютера, на котором возникла проблема.
  3. Наименование и версия операционной системы. Если вы работаете под управле нием Windows, получить эту информацию можно, выполнив двойной щелчок на пиктограмме My Computer (Мой компьютер) и выбрав в меню Help (Справка) пункт About (О программе). Для большинства Unix-подобных операционных сис тем эту информацию можно получить через команду uname -a.

Иногда важен объем памяти (физической и виртуальной). При наличии каких-либо сомнений, включите в отчет и эту информацию.

  1. Если вы используете дистрибутив MySQL с исходными текстами, понадобится наименование и номер версии компилятора. Если дистрибутив только бинарный, потребуется его наименование.
  2. Если проблема возникает при компиляции, включите в отчет сообщение об ошиб ке компилятора и несколько строк из контекста, окружающего то место в исход ном коде, где возникла ошибка.
  3. Если mysqld аварийно завершился, сообщите в отчете текст запроса, приводящего к таким последствиям. Обычно это можно сделать, запустив mysqld с включенной опцией протоколирования запросов и заглянув в файл протокола после отказа mysqld.
  4. Если к ошибке имеет отношение таблица базы данных, включите вывод mysqldump —nodata имя_базы_данных имя_таблицы. Это очень просто сделать и это отличный способ получить информацию о любой таблице в базе данных. В резуль тате у нас появится возможность смоделировать сложившуюся у вас ситуацию.
  5. При описании проблем, имеющих отношение к скорости или к оператору SELECT, всегда необходимо включать вывод команды EXPLAIN SELECT ..., а также, по меньшей мере, число строк, которое возвращает оператор SELECT. Также следует включить вывод команды SHOW CREATE TABLE имя_таблицы для каждой таблицы, участвующей в запросе. Чем больше информации о ситуации вы сообщите, тем более вероятно, что кто-то сможет вам помочь. Ниже представлен пример очень хорошего отчета об ошибке. Он может быть отправлен через сценарий mysqlbug. Этот пример использует утилиту командной строки mysql. Отметьте применение ограничителя операторов G для тех из них, чей вывод превышает ширину ото бражения в 80 символов:

mysqlSHOW VARIABLES; mysqlSHOW COLUMNS FROM ...G ;вывод SHOW COLUMNSmysqlEXPLAIN SELECT ...G ;вывод EXPLAIN mysqlFLUSH STATUS; mysqlSELECT ...; Сокращенная версия вывода SELECT, включая время выполнения запросаmysqlSHOW STATUS; ;вывод SHOWSTATUS;

  • Если ошибка или проблема возникает во время работы mysqld, постарайтесь предоставить сценарий, который воспроизводит аномалию. Этот сценарий должен включать все необходимые исходные файлы. Чем ближе к реальности сценарий сможет воспроизвести ситуацию, тем лучше. Если вы можете соста вить воспроизводимый случай тестирования, присылайте его по адресу http://bugs.mysql.com/ для высокоприоритетной обработки. Если вы не можете предоставить сценарий, по крайней мере, включите в отчет вывод команды mysqladmin variables ex tended-status processlist, чтобы дать представление о том, как ваша система настроена.
      • Если вы не можете предоставить случай тестирования в нескольких строках или же случай тестирования слишком большой, чтобы присылать его в группу рас сылки (более 10 строк), вам потребуется сбросить дамп таблиц с помощью mysqldump и создать файл readme с описанием проблемы. Создайте архив своих файлов с помощью утилит tar, gzip или zip и отправьте его через FTP-протокол по адресу ftp://ftp.raysql.com/pub/mysql/upload/. Затем введите описание про блемы в базу данных ошибок по адресу http://bugs.mysql.com/.
      • Если вам кажется, что MySQL выдает странный результат запроса, включите не только собственно результат, а также ваше предположение, каким он должен быть, и опишите основания своих предположений относительно результата.
      • При описании примера возникновения проблемы лучше использовать имена пе ременных, таблиц и так далее такими, какими они были в вашей ситуации, а не придумывать новые имена. Проблема может иметь отношение к имени перемен ной или таблицы. Это случается редко, но лучше подстраховаться и не вносить искажений в описание проблемы. К тому же вам будет проще, да и нам удобней, если вы приведете пример реальной ситуации. Если у вас есть данные, которые вы не хотите показывать всем, их можно отправить через FTP-протокол по адресу ftp://ftp.mysql.com/pub/mysql/upload. Если же информация настолько секрет на, что вы не хотите ее показывать даже нам, тогда приводите пример с изменен ными именами, но это только в крайнем случае.
      • Включите в отчет все опции всех программ, имеющих отношение к ошибочной ситуации, если это возможно. Так, например, укажите опции, которые вы исполь зовали для запуска сервера mysqld, как и опции любых клиентских программ MySQL. Опции программ mysqld, mysql, сценария configure часто являются клю чами к ответу и поэтому очень важны. Никогда не стоит пренебрегать этим. Если вы применяете модули, подобные Perl или РНР, пожалуйста, укажите номера их версий.
      • Если ваш вопрос имеет отношение к системе привилегий, включите в отчет вывод утилит mysqlaccess, mysqladmin reload и все сообщения об ошибках, которые выдаются при попытке подключения. Когда вы проверяете существующие приви легии, то должны сначала запустить mysqlaccess. После этого запустите mysqladmin reload version и попытайтесь подключиться с помощью той про граммы, которая приводила к проблемам.
      • Если вы располагаете модулем исправления ошибки, упомяните в отчете и о нем. Однако не ожидайте, что ваш модуль исправления - это все, что нам нужно или что мы его используем, особенно если переданный отчет об ошибке не включает в себя случай тестирования, который воспроизводит ошибку, фиксируемую моду лем исправления. Мы можем обнаружить проблемы, связанные с вашим модулем исправления, или вообще не понять его. Если так случится, мы не станем его ис пользовать. Если мы не можем проверить, для чего предназначен данный модуль исправления, мы также не станем его использовать. В этом нам помогут случаи тестирования. Покажите, что модуль исправления справляется со всеми ситуа циями, которые могут возникнуть. Если мы обнаружим какие-то ограничения (даже очень редкие), при которых модуль исправления не работает, он может не пригодиться.
      1. Предположения о природе обнаруженной ошибки, причинах ее возникновения или зависимостях, как правило, неверны. Даже группа разработчиков MySQL не может делать каких-то предположений, пока не воспользуется средствами отлад ки для нахождения истинной причины ошибки.
      2. Отмечайте в отчете об ошибке, что вы просматривали руководство и архивы спи сков рассылки, чтобы остальные знали, что вы пытались решить проблему само стоятельно.
      3. Если вы получили сообщение об ошибке parse error (ошибка синтаксического анализа), тщательно проверьте код на предмет корректности синтаксиса. Если вы не находите в нем ничего некорректного, вполне возможно, что ваша версия сер вера MySQL не поддерживает используемый вами синтаксис. Если вы используе те текущую версию сервера и руководство на http://dev.mysql.com/doc/ не опи сывает применяемый вами синтаксис, значит, сервер MySQL подобный запрос не поддерживает. В этом случае единственный выход для вас - реализовать требуемый синтаксис самостоятельно или отправить письмо по адресу licensing@mysql. com с просьбой реализовать его. Если в руководстве описан син таксис, который вы применяете, но у вас более старая версия сервера MySQL, стоит просмотреть хронологию изменений MySQL, чтобы найти, когда этот син таксис был реализован. В этом случае у вас есть возможность обновить сервер MySQL до более новой версии.
      4. Если возникшая проблема связана с повреждением данных, либо ошибки возни кают при попытке обращения к отдельной таблице, потребуется сначала прове рить, а затем восстановить таблицы с помощью команд CHECK TABLE и REPAIR TABLE, либо с помощью утилиты myisamchk. Если вы работаете в среде Windows, убедитесь, что команда SHOW variables like 'lower_case_table_namesf возвра щает значение 1 или 2.
      5. Если повреждения таблиц случаются часто, попытайтесь выяснить, когда и поче му это происходит. В этом случае протокол ошибок в словаре данных MySQL может содержать некоторую информацию о том, что происходит. (Это файл с суффиксом . err в имени). Включите в отчет об ошибке любую важную информа цию из этого файла. Обычно mysqld никогда не портит таблиц, если только ничто не уничтожает его в процессе обновления данных. Если вы сможете выяснить при чину краха mysqld, нам будет значительно легче помочь вам решить проблему.
      6. Если возможно, загрузите и установите самую последнюю версию сервера MySQL и проверьте, осталась ли проблема нерешенной. Все версии программного обеспечения MySQL тестируются очень тщательно и должны функционировать без проблем. Мы стараемся обеспечить обратную совместимость, насколько это воз можно, поэтому переход на новую версию должен пройти без особых проблем.

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

      Рекомендации по составлению ответов на вопросы из списков рассылки Если вы считаете, что ваш ответ может заинтересовать многих, возможно, имеет смысл отправить его в список рассылки вместо того, чтобы отвечать персонально тому, кто задал вопрос. Постарайтесь максимально обобщить ответ, дабы он принес пользу и другим, а не только тому, кто спрашивает. Отправляя ответ в список рассылки, убедитесь, что он не дублирует предыдущие ответы на тот же вопрос. Постарайтесь подытожить существенную часть вопроса в ответе, но не считайте необходимым полностью цитировать оригинальный вопрос. Не отправляйте почтовых сообщений с помощью браузера с включенным режимом HTML. Многие пользователи читают письма, не прибегая к услугам браузера.