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

5.9.1.6 mysqld でのエラーの原因を見つけるためのサーバーログの使用

一般クエリーログを有効にして mysqld を起動する前に、myisamchk を使用してすべてのテーブルをチェックしてください。 第5章「MySQL サーバーの管理」 を参照してください。

mysqld が異常終了またはハングアップする場合は、一般クエリーログを有効にして mysqld を起動してください。 セクション5.4.3「一般クエリーログ」を参照してください。 mysqld がふたたび異常終了したら、ログファイルの最後の部分を調査して、mysqld が強制終了されたクエリーを見つけることができます。

デフォルトの一般クエリーログファイルを使用した場合、ログはデータベースディレクトリに host_name.log として格納されます。ほとんどの場合、mysqld が強制終了されたのはログファイル内の最後のクエリーですが、可能であれば、mysqld を再起動して、見つかったクエリーを mysql コマンド行ツールから実行することによって、このことを検証してください。 これが機能する場合は、完了しなかった複雑なクエリーもすべてテストする必要があります。

また、長い時間がかかるすべての SELECT ステートメントに対して EXPLAIN コマンドを試すことで、mysqld がインデックスを適切に使用していることを確認できます。 セクション13.8.2「EXPLAIN ステートメント」を参照してください。

実行に長い時間がかかるクエリーを見つけるには、スロークエリーログを有効にして mysqld を起動します。 セクション5.4.5「スロークエリーログ」を参照してください。

エラーログ (通常は host_name.err という名前のファイル) にテキスト mysqld restarted が見つかった場合、mysqld が失敗する原因となるクエリーが見つかった可能性があります。 これが発生した場合、myisamchk を使用してすべてのテーブルをチェックし (第5章「MySQL サーバーの管理」を参照してください)、MySQL ログファイル内のクエリーをテストして、失敗するかどうかを確認します。 そのようなクエリーが見つかった場合は、まず最新バージョンの MySQL にアップグレードすることを試してください。 問題が解決しない場合は、バグを報告してください。セクション1.6「質問またはバグをレポートする方法」 を参照してください。

myisam_recover_options システム変数を設定して mysqld を起動した場合、MyISAM テーブルが正しくクローズされていないまたはクラッシュとマークされていれば、MySQL によって自動的にチェックされ、修復が試行されます。 これが発生した場合、MySQL は hostname.err ファイルに「警告: テーブル ... をチェックしています」と書き込み、テーブルを修復する必要がある場合は、「警告: テーブルを修復しています」がそのあとに書き込まれます。 これらのエラーを多数受け取り、その直前に予期しない mysqld の停止がなかった場合は、何らかの問題があるため、さらに調査する必要があります。 セクション5.1.7「サーバーコマンドオプション」を参照してください。

サーバーは、MyISAM テーブルの破損を検出すると、ソースファイルの名前や行番号、テーブルにアクセスするスレッドのリストなどの追加情報をエラーログに書き込みます。 たとえば、「thread_id=1 からエラーを受け取りました。mi_dynrec.c:368」です。 これは、バグレポートに含めると役に立つ情報です。

mysqld が予期せず異常終了することは良い兆候ではありませんが、この場合は Checking table... メッセージを調査するのではなく、mysqld が異常終了した原因を見つけるようにしてください。