MySQL サーバーが保持するログのうち、診断メッセージを書き込むエラーログです (セクション5.4.2「エラーログ」 を参照)。 通常、サーバーはサーバーホスト上のファイルまたはシステムログサービスに診断を書き込みます。 MySQL 8.0.22 の時点では、エラーログの構成に応じて、サーバーは最新のエラーイベントをパフォーマンススキーマの error_log
テーブルに書き込むこともできます。 したがって、error_log
テーブルに対する SELECT
権限を付与すると、クライアントおよびアプリケーションは SQL クエリーを使用してエラーログの内容にアクセスできるため、DBA はサーバーホストでのファイルシステムへの直接アクセスを許可せずにログにアクセスできます。
error_log
テーブルでは、より構造化されたカラムに基づいてフォーカスされたクエリーがサポートされます。 また、より自由形式の分析をサポートするエラーメッセージの全文も含まれています。
テーブルの実装では、固定サイズのメモリー内リングバッファが使用され、必要に応じて古いイベントが自動的に破棄され、新しいイベント用の領域が確保されます。
error_log
コンテンツの例:
mysql> SELECT * FROM performance_schema.error_log\G
*************************** 1. row ***************************
LOGGED: 2020-08-06 09:25:00.338624
THREAD_ID: 0
PRIO: System
ERROR_CODE: MY-010116
SUBSYSTEM: Server
DATA: mysqld (mysqld 8.0.23) starting as process 96344
*************************** 2. row ***************************
LOGGED: 2020-08-06 09:25:00.363521
THREAD_ID: 1
PRIO: System
ERROR_CODE: MY-013576
SUBSYSTEM: InnoDB
DATA: InnoDB initialization has started.
...
*************************** 65. row ***************************
LOGGED: 2020-08-06 09:25:02.936146
THREAD_ID: 0
PRIO: Warning
ERROR_CODE: MY-010068
SUBSYSTEM: Server
DATA: CA certificate /var/mysql/sslinfo/cacert.pem is self signed.
...
*************************** 89. row ***************************
LOGGED: 2020-08-06 09:25:03.112801
THREAD_ID: 0
PRIO: System
ERROR_CODE: MY-013292
SUBSYSTEM: Server
DATA: Admin interface ready for connections, address: '127.0.0.1' port: 33062
error_log
テーブルには次のカラムがあります。 説明に示されているように、DATA
カラム以外のすべてのカラムは、セクション5.4.2.3「エラーイベントフィールド」 で説明されている基礎となるエラーイベント構造のフィールドに対応します。
-
LOGGED
マイクロ秒精度のイベントタイムスタンプ。
LOGGED
は、エラーイベントのtime
フィールドに対応していますが、次のような違いが考えられます:エラーログの
time
値は、log_timestamps
システム変数の設定に従って表示されます。初期起動時のロギング出力形式 を参照してください。LOGGED
カラムには、TIMESTAMP
データ型を使用して値が格納されます。値は UTC で格納されますが、現在のセッションタイムゾーンで取得されると表示されます。セクション11.2.2「DATE、DATETIME、および TIMESTAMP 型」 を参照してください。
エラーログファイルに表示されているのと同じタイムゾーンで
LOGGED
値を表示するには、最初にセッションタイムゾーンを次のように設定します:SET @@session.time_zone = @@global.log_timestamps;
log_timestamps
値がUTC
で、システムに名前付きタイムゾーンサポートがインストールされていない場合 (セクション5.1.15「MySQL Server でのタイムゾーンのサポート」 を参照)、タイムゾーンを次のように設定します:SET @@session.time_zone = '+00:00';
-
THREAD_ID
MySQL スレッド ID。
THREAD_ID
は、エラーイベントのthread
フィールドに対応します。パフォーマンススキーマ内では、
error_log
テーブルのTHREAD_ID
カラムはthreads
テーブルのPROCESSLIST_ID
カラムにもっとも似ています:フォアグラウンドスレッドの場合、
THREAD_ID
およびPROCESSLIST_ID
は接続識別子を表します。 これは、INFORMATION_SCHEMA
PROCESSLIST
テーブルのID
カラムに表示される値と同じで、SHOW PROCESSLIST
出力のId
カラムに表示され、スレッド内のCONNECTION_ID()
関数によって返されます。バックグラウンドスレッドの場合、
THREAD_ID
は 0、PROCESSLIST_ID
はNULL
です。
error_log
以外の「多数のパフォーマンススキーマ」テーブルにはTHREAD_ID
という名前のカラムがありますが、これらのテーブルでは、THREAD_ID
カラムはパフォーマンススキーマによって内部的に割り当てられた値です。 -
PRIO
イベントの優先度。 許可される値は
System
,Error
,Warning
,Note
です。PRIO
カラムは、エラーイベントのlabel
フィールドに基づいており、それ自体は基礎となる数値prio
フィールド値に基づいています。 -
ERROR_CODE
数値のイベントエラーコード。
ERROR_CODE
は、エラーイベントのerror_code
フィールドに対応します。 -
SUBSYSTEM
イベントが発生したサブシステム。
SUBSYSTEM
は、エラーイベントのsubsystem
フィールドに対応します。 -
DATA
エラーイベントのテキスト表現。 この値の形式は、
error_log
行を生成するログシンクコンポーネントによって生成される形式によって異なります。 たとえば、ログシンクがlog_sink_internal
またはlog_sink_json
の場合、DATA
の値はそれぞれ従来の形式または JSON 形式のエラーイベントを表します。 (セクション5.4.2.9「エラーログ出力形式」を参照してください。)エラーログを再構成して、
error_log
テーブルに行を提供するログシンクコンポーネントを変更できます。また、異なるシンクによって異なる出力形式が生成されるため、異なるタイミングでerror_log
テーブルに書き込まれる行に異なるDATA
形式を設定できます。
error_log
テーブルには次のインデックスがあります:
主キー (
LOGGED
)(
THREAD_ID
) のインデックス(
PRIO
) のインデックス(
ERROR_CODE
) のインデックス(
SUBSYSTEM
) のインデックス
TRUNCATE TABLE
は、error_log
テーブルに対して許可されていません。
パフォーマンススキーマ error_log
テーブルは、エラーログにフォーマットされたエラーイベントを書き込むだけでなく、テーブルに書き込むエラーログシンクコンポーネントによって移入されます。 ログシンクによるパフォーマンススキーマのサポートには、次の 2 つの部分があります:
ログシンクは、発生時に新しいエラーイベントを
error_log
テーブルに書き込むことができます。ログシンクは、以前に書き込まれたエラーメッセージを抽出するためのパーサーを提供できます。 これにより、サーバーインスタンスは前のインスタンスによってエラーログファイルに書き込まれたメッセージを読み取って、
error_log
テーブルに格納できます。 前のインスタンスによって停止中に書き込まれたメッセージは、停止が発生した理由の診断に役立つ場合があります。
現在、従来の形式の log_sink_internal
および JSON 形式の log_sink_json
シンクは、error_log
テーブルへの新しいイベントの書込みをサポートし、以前に書き込まれたエラーログファイルを読み取るパーサーを提供しています。
log_error_services
システム変数は、エラーロギングを有効にするログコンポーネントを制御します。 この値は、エラーイベントが発生したときに左から右の順に実行されるログフィルタおよびログシンクコンポーネントのパイプラインです。 log_error_services
の値は、次のように error_log
テーブルへの移入に関連します:
-
起動時に、サーバーは
log_error_services
値を調べ、次の条件を満たす左端のログシンクから選択します:error_log
テーブルをサポートし、パーサーを提供するシンク。存在しない場合、
error_log
テーブルをサポートするがパーサーを提供しないシンク。
これらの条件を満たすログシンクがない場合、
error_log
テーブルは空のままです。 それ以外の場合、シンクがパーサーを提供し、以前に書き込まれたエラーログファイルを検出できるようにすると、サーバーはシンクパーサーを使用してファイルの最後の部分を読み取り、そこに含まれる古いイベントをテーブルに書き込みます。 その後、シンクは新しいエラーイベントを発生時にテーブルに書き込みます。 -
実行時に、
log_error_services
の値が変更されると、サーバーは再度その値を調べ、今度はerror_log
テーブルをサポートする左端に有効なログシンクを探して、パーサーを提供するかどうかを確認します。そのようなログシンクが存在しない場合、追加のエラーイベントは
error_log
テーブルに書き込まれません。 それ以外の場合、新しく構成されたシンクは、新しいエラーイベントを発生時にテーブルに書き込みます。
エラーログに書き込まれる出力に影響する構成は、error_log
テーブルの内容に影響します。 これには、冗長性、メッセージ抑制、メッセージフィルタリングなどの設定が含まれます。 また、起動時に以前のログファイルから読み取られた情報にも適用されます。 たとえば、冗長性が低い状態で構成された以前のサーバーインスタンス中に書き込まれなかったメッセージは、冗長性が高い状態で構成された現在のインスタンスによってファイルが読み取られた場合は使用できなくなります。
error_log
テーブルは固定サイズのメモリー内リングバッファのビューで、新しいイベント用の領域を確保するために、必要に応じて古いイベントが自動的に破棄されます。 次のテーブルに示すように、いくつかのステータス変数は、進行中の error_log
操作に関する情報を提供します。
ステータス変数 | 意味 |
---|---|
Error_log_buffered_bytes |
テーブルで使用されるバイト数 |
Error_log_buffered_events |
テーブルに存在するイベント |
Error_log_expired_events |
テーブルから破棄されたイベント |
Error_log_latest_write |
テーブルへの最終書込み時間 |