5.2.2 エラーログ

エラーログには mysqld が開始および停止された時期を示す情報と、サーバーが実行中に発生したあらゆるクリティカルエラーが格納されます。自動的にチェックまたは修復することが必要なテーブルが mysqld で検出された場合、エラーログに警告メッセージが書き込まれます。

オペレーティングシステムによっては、mysqld が異常終了した場合にエラーログにスタックトレースが記録されます。トレースを使用して、mysqld が異常終了したかどうかを判断することができます。セクション24.4「MySQL のデバッグおよび移植」 を参照してください。

mysqld_safe を使用して mysqld が開始され、mysqld が予期せず異常終了した場合、mysqld_safe はこれを検出し、mysqld を再起動し、restarted mysqld メッセージをエラーログに書き込みます。

次の説明で、コンソールは標準エラー出力 stderr を意味し、標準エラー出力がリダイレクトされていないかぎり、これはユーザーのターミナルウィンドウまたはコンソールウィンドウです。(たとえば、--syslog オプションを指定して起動した場合、あとで説明するように、mysqld_safe ではサーバーの stderrsyslog に送信されるような調整が行われます。)

Windows で、--log-error および --console オプションは、両方ともエラーロギングに影響します。

  • --log-error を指定しない場合、mysqld はデータディレクトリ内の host_name.err にエラーメッセージを書き込みます。

  • --log-error[=file_name] を指定した場合、mysqld はエラーログファイルにエラーメッセージを書き込みます。指定されたファイルが存在する場合、サーバーはそのファイルを使用し、別のディレクトリを指定する絶対パス名が指定されている場合を除き、そのファイルをデータディレクトリ内に作成します。ファイルが指定されない場合、デフォルト名は、データディレクトリ内の host_name.err です。

  • --console を指定した場合、mysqld は、--log-error がさらに指定される場合を除き、エラーメッセージをコンソールに書き込みます。両方のオプションが存在する場合、--console は無視されて効果がなくなります。それらの順序は関係なく、--log-error が優先されて、エラーメッセージがログファイルに記録されます。

さらに Windows では、サーバーはイベントおよびエラーメッセージをアプリケーションログ内の Windows イベントログに書き込みます。Warning および Note のマークが付いたエントリは、イベントログに書き込まれますが、個々のストレージエンジンからの情報ステートメントなどの情報メッセージは書き込まれません。これらのログエントリのソースは MySQL です。Windows イベントログへの情報の書き込みを無効にすることはできません。

Unix および Unix に類似したシステムでは、mysqld はエラーログメッセージを次のように書き込みます。

  • --log-error を指定しない場合、mysqld はエラーメッセージをコンソールに書き込みます。

  • --log-error[=file_name] を指定した場合、mysqld はエラーログファイルにエラーメッセージを書き込みます。指定されたファイルが存在する場合、サーバーはそのファイルを使用し、別のディレクトリを指定する絶対パス名が指定されている場合を除き、そのファイルをデータディレクトリ内に作成します。ファイルが指定されない場合、デフォルト名は、データディレクトリ内の host_name.err です。

    注記

    Yum または APT パッケージインストールでは、サーバー構成ファイル内の log-error=/var/log/mysqld.log のようなエントリによって、エラーログの場所を /var/log の下に構成することが一般的です。エントリからファイル名を削除すると、エラーログの場所がそのデフォルト設定であるデータディレクトリに戻されます。

エラー出力がファイルに書き込まれる場合、実行時に、log_error システム変数がエラーログファイル名を示します。

オプションファイル内の [mysqld][server]、または [mysqld_safe] セクションに --log-error を指定した場合、mysqld_safe はオプションを検出して使用します。

FLUSH LOGS または mysqladmin flush-logs を使用してログをフラッシュし、mysqld がエラーログをファイルに書き込む場合 (たとえば、--log-error オプションを使用して開始された場合)、サーバーはログファイルを閉じて再オープンします。ファイルを名前変更するには、フラッシュする前にこれを手動で実行します。そのあとでログをフラッシュすると、新しいファイルが元のファイル名で再オープンします。たとえば、次のコマンドを使用して、ファイルを名前変更し、新しいファイルを作成することができます。

shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory

Windows では、mv の代わりに rename を使用してください。

サーバーが指定されたファイルに書き込まない場合、ログがフラッシュされたときにエラーログの名前変更は実行されません。

mysqld_safe を使用して mysqld を開始した場合、mysqld_safe では mysqld がエラーメッセージをログファイルまたは syslog に書き込むような調整が行われます。mysqld_safe には --syslog--skip-syslog、および --log-error の 3 つのエラーロギングオプションがあります。ロギングオプションを指定しないか --skip-syslog を指定した場合のデフォルトは、デフォルトログファイルを使用することです。エラーログファイルの使用を明示的に指定する場合、--log-error=file_namemysqld_safe に指定すると、mysqld_safe では mysqld がメッセージをログファイルに書き込むような調整が行われます。syslog を代わりに使用するには、--syslog オプションを指定します。

--log-warnings オプションまたは log_warnings システム変数を使用すると、エラーログへの警告ロギングを制御できます。デフォルト値は有効化 (1) です。値 0 を使用して警告ロギングを無効にすることができます。値が 1 より大きい場合、中止された接続がエラーログに書き込まれ、新しい接続の試行についてのアクセス拒否エラーが書き込まれます。セクションB.5.2.11「通信エラーおよび中止された接続」を参照してください。


User Comments
  Posted by Jonathan Lampe on September 23, 2004
I did some testing with MySQL 4.0.21 this morning. Here's a typical snippet from my "hostname.err" file. To generate this, I did a "NET START MySQL", connected with one session and ran a 2000-entry query, and then did a "NET STOP MySQL" while the query was still returning data.

MySql: ready for connections.
Version: '4.0.21-nt-log' socket: '' port: 3306 Source distribution
040923 10:00:00 MySql: Normal shutdown
040923 10:00:01 MySql: Forcing close of thread 1 user: 'root'
040923 10:00:01 InnoDB: Starting shutdown...
040923 10:00:03 InnoDB: Shutdown completed
040923 10:00:03 MySql: Shutdown Complete

The Windows Application Event Log recorded 3 messages at the same time. All of the messages corresponded with the entries prefixed with the "MySQL:" entries in the hostname.err file. (OK)

However, all 3 messages were logged as ERRORS; this designation is misleading. If anything, the "Normal Shutdown" and "Shutdown Complete" messages should have been logged as INFORMATION and the "Forcing close of thread..." message should have been logged as a WARNING.

Also, it is important to note that the MySQL service startup was NOT LOGGED in the Event Log.

Long story short, if you are a Windows user, it is probably still best (as of 4.0.21) to stick with your existing "parse-the-.err" script rather than rely on the Windows Event Log if you're interested in MySQL service starts, stops and abnormal events.
Sign Up Login You must be logged in to post a comment.