MySQL :: MySQL 8.0 リファレンスマニュアル :: 1.6 質問またはバグをレポートする方法

9.1 English
9.0 English
8.4 English
8.0 English
5.7 English

MySQL 8.0 リファレンスマニュアル / 一般情報 / 質問またはバグをレポートする方法

このページは機械翻訳したものです。

1.6 質問またはバグをレポートする方法

問題についてバグレポートを投稿する前に、それが実際にバグであることと、バグがまだレポートされていないことを確認してください。

まず、https://dev.mysql.com/doc/ で MySQL オンラインマニュアルを検索してください。マニュアルは、常に最新の状態にしておくために、新しく見つかった問題に対する解決策によって頻繁に更新されています。また、問題に関する解決方法が新しいバージョンにすでに組み込まれている可能性が高いので、マニュアルに付随するリリースノートは特に有用です。リリースノートはマニュアル用の場所から入手可能です。
SQL ステートメントに対するパースエラーが生じた場合は、構文を念入りにチェックしてください。そこで問題が見当たらなければ、現在使用している MySQL Server のバージョンが、使用されている構文をサポートしていない可能性が高くなります。最新のバージョンを使用しており、マニュアルが使用された構文をカバーしていない場合、MySQL Server はそのステートメントをサポートしません。

マニュアルがその構文をカバーしているが、MySQL Server が旧バージョンの場合、MySQL の変更履歴を調べ、いつその構文が実装されたのかを確認してください。この場合、新しいバージョンの MySQL Server へアップグレードするという選択肢もあります。
一般的な問題の解決法については次を参照してください。セクションB.3「問題および一般的なエラー」。
http://bugs.mysql.com/ でバグデータベースを検索して、バグがすでにレポートおよび解決されているかどうかを確認します。
http://www.mysql.com/search/ を使用して、MySQL web サイトにあるすべての Web ページ (マニュアルを含む) を検索することもできます。

マニュアル、バグデータベース、およびメーリングリストのアーカイブで回答を見つけることができなかった場合、お近くの MySQL の専門家にお問い合わせください。それでも質問に対する回答を見つけることができなかった場合は、次のガイドラインに従ってバグをレポートしてください。

通常バグをレポートする場合は、http://bugs.mysql.com/ にアクセスしてください。これはバグデータベースのアドレスです。このバグデータベースは一般に公開されているので、だれでも参照および検索することができます。システムにログインすると、新しいレポートを入力できます。

http://bugs.mysql.com/ のバグデータベースに投稿され、所定のリリースで修正されたバグは、リリースノートに記載されます。

MySQL Server でセキュリティバグが見つかった場合は、<secalert_us@oracle.com> に電子メールメッセージを送信して、すぐにお知らせください。例外: サポートのお客様は、セキュリティーのバグを含むすべての問題を http://support.oracle.com/ の Oracle Support までレポートしてください。

他のユーザーとの問題について話し合うには、MySQL Community Slack を使用できます。

よいバグレポートを書くのは時間がかかるものですが、最初に正しく行うことで報告者と弊社の双方の時間を節約できます。そのバグの完全なテストケースを含むよいバグレポートを提供していただければ、次回のリリースではその問題を修正できる可能性が非常に高くなります。このセクションでは、あまり役に立たないことをして時間を無駄にすることがないよう、レポートの正しい書き方を紹介します。このセクションを注意深く読み、ここに記載されているすべての情報がレポートに含まれているか、確認してください。

できれば、MySQL Server の最新の製品版または開発版を使用して問題をテストしてから投稿してください。テストケースに対して mysql test < script_file を使用するか、バグレポートに含まれているシェルまたは Perl のスクリプトを実行するだけで、だれでもバグを再現できるはずです。弊社で再現が可能なバグであれば、次回の MySQL リリースで修正される可能性が高くなります。

問題に関する適切な説明がバグレポートに記載されていると、もっとも効果的です。そのため、問題につながったすべての操作の適切な例を挙げ、問題自体を詳細に記述してください。もっとも効果的なレポートは、バグや問題を再現する方法を示す詳細な例が記載されたものです。セクション5.9「MySQL のデバッグ」を参照してください。

情報が多すぎるレポートに対応することはできますが、少なすぎるレポートに対応することはできません。多くの場合、問題の原因がわかっていると思い、細部を重要でないと考えるため、事実を省略してしまいます。記載するかどうかを迷ったときは、記載することをお勧めします。最初のレポートに十分な情報を記載していなかったために、再度質問して回答を待たなければならなくなるよりも、レポートに数行を追加する方が、はるかに時間が節約される上に、煩わしくありません。

バグレポートでもっともよくある誤りは、(a) 使用している MySQL ディストリビューションのバージョン番号を記載していない、(b) MySQL Server がインストールされているプラットフォームの説明 (プラットフォームの種類およびバージョン番号を含む) が十分でないというものです。これは非常に重要な情報なので、ほとんどの場合、この情報が記載されていないバグレポートは役に立ちません。「なぜうまく動作しないのか ?」という質問が頻繁に寄せられます。その場合、要求した機能がその MySQL バージョンに実装されていなかったり、レポートに記載されているバグが新しい MySQL バージョンですでに修正されていたりすることがあります。エラーがプラットフォーム依存である場合もよくあります。そのような場合、オペレーティングシステムやプラットフォームのバージョン番号を知らないで問題を修正することはほとんど不可能です。

また、MySQL をソースからコンパイルした場合は、コンパイラが問題に関連している場合は、コンパイラに関する情報も記載してください。ユーザーがコンパイラのバグを見つけて、それが MySQL 関連の問題であると考えることがよくあります。ほとんどのコンパイラは常に開発中なので、バージョンごとに改良されています。問題がコンパイラに関連するものであるかどうかを判断するには、使用しているコンパイラを知る必要があります。コンパイルに関するすべての問題はバグとみなし、適宜レポートしてください。

プログラムでエラーメッセージが生成された場合、そのメッセージをレポートに記載することが非常に重要です。アーカイブから情報を検索しようとする場合、レポートされたエラーメッセージがプログラムで生成されたものと正確に一致している方が効果的です。 (大文字小文字の違いにも注意してください。) エラーメッセージ全体をレポートにコピー&ペーストしてください。記憶に頼ってエラーメッセージを思い出そうとしないでください。

Connector/ODBC (MyODBC) に関する問題がある場合、トレースファイルを生成し、レポートともに送信してください。 How to Report Connector/ODBC Problems or Bugs を参照してください。

レポートに、mysql コマンド行ツールを使用して実行したテストケースからの長いクエリー出力が含まれる場合、--vertical オプション (または \G ステートメントターミネータ) を使用すると、読みやすくなります。このセクションで後述される EXPLAIN SELECT の例では、\G の使用方法を示します。

レポートには次の情報を記載してください。

使用している MySQL ディストリビューションのバージョン番号 (MySQL 5.7.10 など)。実行しているバージョンを確認するには、mysqladmin version を実行します。 mysqladmin プログラムは、MySQL インストールディレクトリの下の bin ディレクトリにあります。
問題が発生したマシンの製造元とモデル。
オペレーティングシステムの名前とバージョン。 Windows を使用している場合、名前とバージョン番号を取得するには、通常「マイコンピュータ」アイコンをダブルクリックし、「ヘルプ/バージョン情報」メニューをプルダウンします。ほとんどの Unix 系のオペレーティングシステムでは、この情報を取得するには、コマンド uname -a を実行します。
メモリー (実メモリーと仮想メモリー) の量が関連することもあります。不確かな場合は、これらの値を記載します。
MySQL インストールの docs/INFO_BIN ファイルの内容。このファイルには、MySQL の構成およびコンパイル方法に関する情報が含まれています。
MySQL ソフトウェアのソースディストリビューションを使用している場合、使用したコンパイラの名前とバージョン番号を記載します。バイナリディストリビューションを使用している場合は、ディストリビューション名を記載します。
コンパイル時に問題が発生した場合、正確なエラーメッセージ、およびエラーが発生したファイル内の問題のあるコード付近の数行のコンテキストを記載します。
mysqld が停止した場合は、mysqld が予期せず終了する原因となったステートメントも報告する必要があります。通常、この情報を取得するには、クエリーロギングを有効にして mysqld を実行し、mysqld の終了後にログを参照します。セクション5.9「MySQL のデバッグ」を参照してください。
データベーステーブルが問題に関連している場合、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_MODE
FROM INFORMATION_SCHEMA.ROUTINES;
```
トリガーに対しては次のステートメントが利用できます。
```
SELECT EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE, TRIGGER_NAME, SQL_MODE
FROM 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 variables extended-status processlist からの出力をレポートに記載して、システムの動作に関する情報を提供してください。
数行ではテストケースを再現できない場合や、テストテーブルが大きすぎてバグレポートに含めることができない場合 (10 行を超える場合)、mysqldump を使用してテーブルをダンプし、問題を説明する README ファイルを作成してください。 tar と gzip または zip を使用してファイルの圧縮アーカイブを作成します。 http://bugs.mysql.com/ のバグデータベースのバグレポートを開始してから、バグレポートの「ファイル」タブをクリックして、アーカイブをバグデータベースにアップロードする指示に従ってください。
MySQL Server でステートメントから正しくない結果が生成されたと思う場合、結果だけでなく、正しいと考える結果と、その考えの根拠を示す説明も記載します。
問題のサンプルを提供する際には、テーブル名や変数名などは、新しい名前を使用するよりも実際の状況で存在するものを使用するのが適切です。問題が、テーブルや変数の名前に関連している可能性があります。このようなケースはほとんどないと思われますが、後悔するよりも安全策をとるべきです。結局、実際の状況に基づいたサンプルを提供する方がユーザーにとって簡単であると同時に、当社にとっても効率的です。バグレポート内に、ほかのユーザーに公開したくないデータがある場合は、前述のように「ファイル」タブを使用してアップロードできます。データが実際に最高機密で、当社にも公開したくない場合は、ほかの名前を使用したサンプルを提供することもできますが、これは最後の選択肢です。
可能な場合、関連するプログラムのすべてのオプションを記載します。たとえば、mysqld サーバーを開始する際に使用したオプションや MySQL クライアントプログラムの実行に使用したオプションを記載します。 mysqld や mysql のようなプログラムや、configure スクリプトのオプションは多くの場合、問題解決の鍵となり、非常に重要です。これらを記載することは、決して無駄ではありません。問題が、Perl や PHP などの言語で記述されたプログラムに関係する場合は、言語プロセッサーのバージョン番号だけでなく、プログラムが使用するモジュールのバージョンも記載します。たとえば、DBI モジュールや DBD::mysql モジュールを使用する Perl スクリプトがある場合、Perl、DBI、および DBD::mysql のバージョン番号を記載します。
質問が権限システムに関連する場合は、mysqladmin reload の出力と、接続しようとしたときに表示されるすべてのエラーメッセージを含めてください。権限をテストする場合は、mysqladmin reload version を実行し、問題のあるプログラムに接続してみてください。
バグのパッチがある場合、それを含めます。ただし、当社はパッチだけを必要としているわけではありません。パッチによって修正されるバグを示すテストケースなどの必要な情報が記載されていない場合、当社はそのパッチを使用できません。当社がパッチに関連する問題を見つける場合もあれば、パッチをまったく理解できない場合もあります。そのような場合は、パッチを使用できません。

パッチの目的を正確に確認することができない場合、当社はそのパッチを使用しません。この場合、テストケースが役立つことになります。発生する可能性があるすべての状況がパッチによって処理されることを示してください。パッチが機能しないボーダーラインケースが見つかった場合 (それがまれなケースでも) 、そのパッチは役に立たない可能性があります。
何がバグであるか、そのバグがなぜ発生するのか、そのバグが何に関連するのかについての推測は、間違っていることが多いです。 MySQL チームでさえも、最初にデバッガを使用しなければ、そのようなことを推測してバグの実際の原因を特定することはできません。
ユーザー自身で問題を解決しようとしたことがほかのユーザーにわかるように、リファレンスマニュアルやメールアーカイブを確認したことをバグレポートに記載します。
データが壊れていると思われる場合や、特定のテーブルにアクセスした際にエラーが発生した場合は、まず CHECK TABLE でテーブルをチェックしてください。そのステートメントでエラーがレポートされた場合、
- InnoDB クラッシュリカバリメカニズムは、サーバーが強制終了したあとに再起動した場合にクリーンアップを処理します。そのため、通常の操作ではテーブルを「修復」する必要はありません。 InnoDB テーブルでエラーが生じる場合は、サーバーを再起動して問題が継続するかどうか、またはエラーがメモリー内のキャッシュデータのみに影響するのかを確認します。ディスク上のデータが壊れている場合、影響を受けたテーブルをダンプできるように、innodb_force_recovery オプションを有効にして再起動してみてください。
- トランザクショナルでないテーブルについては、REPAIR TABLE または myisamchk を使用して修復を試みてください。第5章「MySQL サーバーの管理」を参照してください。
Windows を実行している場合は、lower_case_table_names の値を SHOW VARIABLES LIKE 'lower_case_table_names' ステートメントを使用して確認します。この変数は、データベースおよびテーブル名の大文字/小文字をサーバーがどのように扱うかに対して影響を与えます。ある値に対しての効果はセクション9.2.3「識別子の大文字と小文字の区別」で説明されているとおりです。
テーブルが頻繁に壊れる場合、その問題が発生する状況と理由を特定する必要があります。この場合、MySQL データディレクトリのエラーログに、発生した問題に関する情報が格納されていることがあります。 (そのファイルは、名前に .err のサフィクスが付いたファイルです。) セクション5.4.2「エラーログ」を参照してください。このファイル内の関連する情報をバグレポートに記載します。通常、更新中に何も強制終了しなかった場合、mysqld はテーブルを破損させないでください。 mysqld が停止した原因が特定されれば、当社はその問題の解決策をはるかに簡単に提供できます。セクションB.3.1「問題の原因を判別する方法」を参照してください。
可能な場合、最新バージョンの MySQL Server をダウンロードしてインストールし、これによって問題が解決されるかどうかを確認します。 MySQL ソフトウェアのすべてのバージョンが詳細にテストされているため、問題なく動作するはずです。すべてにおいて最大限の下位互換性が確保されているため、MySQL のバージョンを問題なく切り替えることができると当社は確信しています。セクション2.1.2「インストールする MySQL のバージョンと配布の選択」を参照してください。

PREV HOME UP NEXT