各エラーログシンク (ライター) コンポーネントには、宛先へのメッセージの書込みに使用される特性出力形式がありますが、他の要因がメッセージの内容に影響する場合があります:
ログシンクで使用可能な情報。 シンクコンポーネントの実行前に実行されたログフィルタコンポーネントによってログイベントフィールドが削除された場合、そのフィールドは書込みできません。 ログのフィルタリングの詳細は、セクション5.4.2.4「エラーログフィルタリングのタイプ」 を参照してください。
ログシンクに関連する情報。 すべてのシンクがエラーイベントで使用可能なすべてのフィールドを書き込むわけではありません。
システム変数はログシンクに影響を与える可能性があります。 エラーログ形式に影響するシステム変数を参照してください。
エラーイベントのフィールドの名前と説明は、セクション5.4.2.3「エラーイベントフィールド」 を参照してください。 すべてのログシンクについて、エラーログメッセージに含まれるスレッド ID は、メッセージの書込みを担当する mysqld 内のスレッドのスレッド ID です。 この ID は、サーバーのどの部分がメッセージを生成したかを示し、接続スレッド ID を含む一般クエリーログおよびスロークエリーログメッセージと整合性があります。
内部ログシンクは、従来のエラーログ出力を生成します。 例:
2020-08-06T14:25:02.835618Z 0 [Note] [MY-012487] [InnoDB] DDL log recovery : begin
2020-08-06T14:25:02.936146Z 0 [Warning] [MY-010068] [Server] CA certificate /var/mysql/sslinfo/cacert.pem is self signed.
2020-08-06T14:25:02.963127Z 0 [Note] [MY-010253] [Server] IPv6 is available.
2020-08-06T14:25:03.109022Z 5 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started with id 5従来の形式のメッセージには、次のフィールドがあります:
time thread [label] [err_code] [subsystem] msg
[および]の角カッコ文字は、メッセージ形式のリテラル文字です。 フィールドがオプションであることを示すものではありません。
label 値は、prio エラーイベント優先度フィールドの文字列形式に対応します。
[err_code]および[subsystem]フィールドが MySQL 8.0 に追加されました。 古いサーバーによって生成されたログから欠落しています。 ログパーサーは、これらのフィールドを、それらを含めるために最近サーバーによって書き込まれたログに対してのみ存在するメッセージテキストの一部として処理できます。 パーサーは、[err_code]インジケータの err_code 部分を数値ではなく文字列値として扱う必要があります。これは、MY-012487 や MY-010051 などの値に数値以外の文字が含まれているためです。
JSON 形式のログシンクは、キーと値のペアを含む JSON オブジェクトとしてメッセージを生成します。 例:
{
"prio": 3,
"err_code": 10051,
"source_line": 561,
"source_file": "event_scheduler.cc",
"function": "run",
"msg": "Event Scheduler: scheduler thread started with id 5",
"time": "2020-08-06T14:25:03.109022Z",
"ts": 1596724012005,
"thread": 5,
"err_symbol": "ER_SCHEDULER_STARTED",
"SQL_state": "HY000",
"subsystem": "Server",
"buffered": 1596723903109022,
"label": "Note"
}表示されるメッセージは、読みやすくするために再フォーマットされています。 エラーログに書き込まれたイベントは、行ごとに 1 つのメッセージが表示されます。
ts (タイムスタンプ) キーは MySQL 8.0.20 で追加され、JSON 形式のログシンクに固有です。 この値は、エポック ('1970-01-01 00:00:00' UTC) からのミリ秒数を示す整数です。
ts と buffered の値は Unix のタイムスタンプ値であり、FROM_UNIXTIME() と適切な除数を使用して変換できます:
mysql> SET time_zone = '+00:00';
mysql> SELECT FROM_UNIXTIME(1596724012005/1000.0);
+-------------------------------------+
| FROM_UNIXTIME(1596724012005/1000.0) |
+-------------------------------------+
| 2020-08-06 14:26:52.0050 |
+-------------------------------------+
mysql> SELECT FROM_UNIXTIME(1596723903109022/1000000.0);
+-------------------------------------------+
| FROM_UNIXTIME(1596723903109022/1000000.0) |
+-------------------------------------------+
| 2020-08-06 14:25:03.1090 |
+-------------------------------------------+
サーバーは、起動オプションが処理される前、つまり log_error_verbosity や log_timestamps システム変数の値などのエラーログ設定がわかっている前、および使用されるログコンポーネントがわかっている前に、いくつかのエラーログメッセージを生成します。 サーバーは、起動プロセスの初期段階で生成されるエラーログメッセージを次のように処理します:
MySQL 8.0.14 より前は、サーバーはデフォルトのタイムスタンプ、書式および冗長性レベルでメッセージを生成し、それらをバッファします。 起動オプションが処理され、エラーログ構成がわかった後、サーバーはバッファされたメッセージをフラッシュします。 これらの早期メッセージはデフォルトのログ構成を使用するため、起動オプションで指定されたものとは異なる場合があります。 また、初期メッセージはデフォルト以外のログシンクにフラッシュされません。 たとえば、JSON シンクへのロギングには、JSON 形式ではないため、これらの早期メッセージは含まれません。
-
MySQL 8.0.14 では、サーバーは書式設定されたログメッセージではなくログイベントをバッファします。 これにより、設定がわかった後に構成設定をイベントに遡及的に適用でき、フラッシュされたメッセージではデフォルトではなく構成済の設定が使用されます。 また、メッセージは、デフォルトのシンクだけでなく、構成されているすべてのシンクにフラッシュされます。
ログ構成がわかる前に致命的エラーが発生し、サーバーを終了する必要がある場合、サーバーはロギングのデフォルトを使用してバッファ済メッセージをフォーマットし、失われないようにします。 致命的エラーは発生しないが、起動オプションを処理する前に起動が過度に遅い場合、サーバーはロギングのデフォルトを使用してバッファされたメッセージを定期的にフォーマットおよびフラッシュし、応答しないようにします。 この動作は、デフォルトが使用されるという点で 8.0.14 より前の動作に似ていますが、例外的な条件が発生した場合にメッセージを失うよりも推奨されます。
log_timestamps システム変数は、エラーログ (および一般的なクエリーログファイルとスロークエリーログファイル) に書き込まれるメッセージのタイムスタンプのタイムゾーンを制御します。 サーバーは、ログシンクに到達する前に log_timestamps をエラーイベントに適用するため、すべてのシンクからのエラーメッセージ出力に影響します。
許可される log_timestamps 値は、UTC (デフォルト) および SYSTEM (ローカルシステムのタイムゾーン) です。 タイムスタンプは ISO 8601 / RFC 3339 形式を使用して書き込まれます: YYYY-MM-DDThh:mm:ss.uuuuuu±hh:mm (UTC に対するローカルシステムのタイムゾーン調整を示すオフセット) を示す Z の末尾の値を加えたもの。 例:
2020-08-07T15:02:00.832521Z (UTC)
2020-08-07T10:02:00.832521-05:00 (SYSTEM)