MySQL :: MySQL 8.0 リファレンスマニュアル :: 27.12.19.1 error

9.1 English
9.0 English
8.4 English
8.0 English

MySQL 8.0 リファレンスマニュアル / ... / error_log テーブル

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

27.12.19.1 error_log テーブル

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 テーブルの実装および構成

パフォーマンススキーマ 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`	テーブルへの最終書込み時間

PREV HOME UP NEXT