このページは機械翻訳したものです。
          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_IDMySQL スレッド 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 | テーブルへの最終書込み時間 |