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

5.4.3 一般クエリーログ

一般クエリーログは、mysqld の実行内容の一般的な記録です。 サーバーは、クライアントが接続または接続解除したときに情報をこのログに書き込み、クライアントから受け取った各 SQL ステートメントをログに記録します。 一般クエリーログは、クライアント側でエラーが疑われるとき、クライアントが mysqld に送信した内容を正確に知りたい場合に非常に役立つことがあります。

クライアントが接続するタイミングを示す各行には、using connection_type も含まれ、接続の確立に使用されるプロトコルを示します。connection_type は、TCP/IP (SSL なしで確立された TCP/IP 接続)、SSL/TLS (SSL で確立された TCP/IP 接続)、Socket (Unix ソケットファイル接続)、Named Pipe (Windows 名前付きパイプ接続)、Shared Memory (Windows 共有メモリー接続) のいずれかです。

mysqld は、ステートメントを受け取った順にクエリーログに書き込みますが、ステートメントが実行された順番とは異なることがあります。 このロギング順序はバイナリログの順序とは対照的で、バイナリログの場合、ステートメントはそれが実行されたあと、ロックがリリースされる前に書き込まれます。 さらに、クエリーログはデータを選択するだけのステートメントを格納することもあり、そのようなステートメントはバイナリログには一切書き込まれません。

レプリケーションソースサーバーでステートメントベースのバイナリロギングを使用する場合、その複製によって受信されたステートメントは、各複製のクエリーログに書き込まれます。 クライアントが mysqlbinlog ユーティリティーを使用してイベントを読み取り、サーバーに渡すと、ステートメントはソースのクエリーログに書き込まれます。

ただし、行ベースのバイナリロギングを使用する場合、更新は SQL ステートメントではなく行の変更として送信されるため、binlog_format が ROW の場合、これらのステートメントはクエリーログに書き込まれません。 使用されるステートメントによっては、この変数が MIXED に設定された場合、所定の更新がクエリーログに書き込まれないこともあります。 詳細については、セクション17.2.1.1「ステートメントベースおよび行ベースレプリケーションのメリットとデメリット」を参照してください。

デフォルトでは、一般クエリーログは無効になっています。 初期の一般クエリーログ状態を明示的に指定するには、--general_log[={0|1}] を使用します。 引数を指定しないか、引数が 1 の場合、--general_log によってログが有効になります。 引数が 0 の場合、このオプションによってログが無効になります。 ログファイル名を指定するには、--general_log_file=file_name を使用します。 ログの宛先を指定するには、log_output システム変数 (セクション5.4.1「一般クエリーログおよびスロークエリーログの出力先の選択」 を参照) を使用します。

注記

TABLE ログの保存先を指定する場合は、ログテーブルおよび「「開いているファイルが多すぎます」」エラー を参照してください。

一般クエリーログファイルの名前を指定しない場合、デフォルト名は host_name.log です。 サーバーは、別のディレクトリを指定する絶対パス名が指定されないかぎり、データディレクトリ内にファイルを作成します。

実行時に一般クエリーログを無効化または有効化したり、ログファイル名を変更したりするには、グローバルな general_log および general_log_file システム変数を使用します。 general_log を 0 (または OFF) に設定するとログが無効化され、1 (または ON) にすると有効化されます。 ログファイルの名前を指定するには、general_log_file を指定します。 ログファイルがすでに開いている場合、ログファイルが閉じて新しいファイルが開きます。

一般クエリーログが有効になっている場合、サーバーは log_output システム変数で指定された宛先に出力を書き込みます。 ログを有効にすると、サーバーはログファイルを開き、ログファイルに起動メッセージを書き込みます。 ただし、FILE ログの出力先が選択されないかぎり、ファイルに対するそれ以上のクエリーのロギングは実行されません。 出力先が NONE の場合、一般ログが有効な場合であってもサーバーはクエリーを書き込みません。 ログ出力先の値に FILE が含まれていない場合、ログファイル名を設定してもロギングへの影響はありません。

サーバー再起動およびログフラッシュを行なっても、新しい一般クエリーログファイルは生成されません (ただし、フラッシュではファイルが閉じて再オープンします)。 ファイルを名前変更して新しいファイルを作成するには、次のコマンドを使用します。

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

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

また、ログを無効にすることによって、実行時に一般クエリーログファイルを名前変更することができます。

SET GLOBAL general_log = 'OFF';

ログを無効にして、ログファイルの名前を外部で (たとえば、コマンドラインから) 変更します。 そのあと、ログをふたたび有効にします。

SET GLOBAL general_log = 'ON';

この方法はすべてのプラットフォームで動作し、サーバー再起動を必要としません。

現在のセッションの一般クエリーロギングを無効または有効にするには、セッション sql_log_off 変数を ON または OFF に設定します。 (これは、一般クエリーログ自体が有効になっていることを前提としています。)

一般クエリーログに書き込まれたステートメント内のパスワードは、文字どおりプレーンテキストで発生しないようにサーバーによって書き換えられます。 一般クエリーログについてのパスワードの書き換えは、--log-raw オプションでサーバーを起動することによって抑制できます。 このオプションは、サーバーによって受け取られるステートメントの正確なテキストを表示する際の診断目的で役立つ場合がありますが、セキュリティー上の理由で本番用途では推奨されません。 セクション6.1.2.3「パスワードおよびロギング」も参照してください。

パスワードの書き換えの影響は、解析できないステートメント (構文エラーなど) はパスワードがないことがわかっていないため、一般クエリーログに書き込まれないことです。 エラーが発生したステートメントを含むすべてのステートメントのロギングが必要なユースケースでは、--log-raw オプションを使用する必要があります。これにより、パスワードのリライトもバイパスされることに注意してください。

パスワードの書き換えは、プレーンテキストパスワードが必要な場合にのみ行われます。 パスワードハッシュ値を想定する構文を持つステートメントの場合、書き換えは行われません。 このような構文に対してプレーンテキストパスワードが誤って指定された場合、パスワードはリライトなしで指定されたとおりにログに記録されます。

log_timestamps システム変数は、一般クエリーログファイル (およびスロークエリーログファイルとエラーログ) に書き込まれるメッセージのタイムスタンプのタイムゾーンを制御します。 一般クエリーログおよびログテーブルに書き込まれるスロークエリーログメッセージのタイムゾーンには影響しませんが、これらのテーブルから取得された行は、CONVERT_TZ() を使用するか、セッションの time_zone システム変数を設定することによって、ローカルシステムのタイムゾーンから任意のタイムゾーンに変換できます。