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

MySQL 8.0 リファレンスマニュアル / ... / エラーログ構成

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

5.4.2.1 エラーログ構成

MySQL 8.0 では、エラーロギングはセクション5.5「MySQL のコンポーネント」で説明されている MySQL コンポーネントアーキテクチャを使用します。エラーログサブシステムは、ログイベントのフィルタリングおよび書込みを実行するコンポーネントと、目的のロギング結果を得るために有効にするコンポーネントを構成するシステム変数で構成されます。

このセクションでは、エラーロギングのコンポーネントを選択する方法について説明します。ログフィルタに固有の手順は、セクション5.4.2.4「エラーログフィルタリングのタイプ」を参照してください。 JSON およびシステムログシンクに固有の手順は、セクション5.4.2.7「JSON 形式でのエラーロギング」およびセクション5.4.2.8「システムログへのエラーロギング」を参照してください。使用可能なすべてのログコンポーネントの詳細は、セクション5.5.3「エラーログコンポーネント」を参照してください。

コンポーネントベースのエラーロギングには、次の機能があります:

ログイベントをフィルタコンポーネントでフィルタして、書込み可能な情報に影響を与えることができます。
ログイベントは、シンク (ライター) コンポーネントによって出力されます。複数のシンクコンポーネントを有効にして、エラーログ出力を複数の宛先に書き込むことができます。
組込みフィルタとシンクコンポーネントを組み合せて、デフォルトのエラーログ形式を実装します。
ロード可能なシンクにより、JSON 形式でのロギングが可能になります。
ロード可能なシンクにより、システムログへのロギングが可能になります。
システム変数は、有効にするログコンポーネントおよび各コンポーネントの動作を制御します。

log_error_services システム変数は、エラーロギングを有効にするログコンポーネントを制御します。変数には、0、1 または多数の要素を含むリストを含めることができます。後者の場合、要素はセミコロンまたは (MySQL 8.0.12 の時点で) カンマで区切り、オプションでスペースを続けることができます。指定された設定にセミコロンとカンマの両方のセパレータを使用することはできません。サーバーはリストされた順序でコンポーネントを実行するため、コンポーネントの順序は重要です。

デフォルトでは、log_error_services の値は次のとおりです:

mysql> SELECT @@GLOBAL.log_error_services;
+----------------------------------------+
| @@GLOBAL.log_error_services            |
+----------------------------------------+
| log_filter_internal; log_sink_internal |
+----------------------------------------+

この値は、ログイベントが最初に log_filter_internal フィルタコンポーネントを通過し、次に log_sink_internal シンクコンポーネントを通過することを示します。どちらも組み込まれています。フィルタは、log_error_services 値の後半で指定されたコンポーネントに表示されるログイベントを変更します。シンクは、ログイベントの宛先です。通常、シンクはログイベントを特定の形式のログメッセージに処理し、これらのメッセージをファイルやシステムログなどの関連出力に書き込みます。

注記

log_error_services 値の最終コンポーネントをフィルタにすることはできません。イベントに対する変更は出力に影響しないため、これはエラーです:

mysql> SET GLOBAL log_error_services = 'log_filter_internal';
ERROR 1231 (42000): Variable 'log_error_services' can't be set to the value
of 'log_filter_internal'

問題を修正するには、値の最後にシンクを含めます:

mysql> SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal';
Query OK, 0 rows affected (0.00 sec)

log_filter_internal と log_sink_internal の組合せにより、デフォルトのエラーログのフィルタリングおよび出力動作が実装されます。これらのコンポーネントのアクションは、他のサーバーオプションおよびシステム変数の影響を受けます:

出力先は、--log-error オプション (および Windows、--pid-file および --console の場合) によって決まります。これらは、コンソールまたはファイルにエラーメッセージを書き込むかどうか、およびファイルに書き込む場合はエラーログファイル名を決定します。セクション5.4.2.2「デフォルトのエラーログ保存先の構成」を参照してください。
log_error_verbosity および log_error_suppression_list システム変数は、log_filter_internal が許可または抑制するログイベントのタイプに影響します。セクション5.4.2.5「優先度ベースのエラーログのフィルタリング (log_filter_internal)」を参照してください。

エラーロギングに使用されるログコンポーネントのセットを変更するには、必要に応じてコンポーネントをロードし、コンポーネント固有の構成を実行して、log_error_services 値を変更します。ログコンポーネントの追加または削除には、次の制約があります:

有効なコンポーネントのリストにログコンポーネントを追加するには:
- INSTALL COMPONENT を使用してコンポーネントをロードします (組込みまたはすでにロードされている場合を除く)。
- コンポーネントの初期化を成功させるために設定する必要があるシステム変数がコンポーネントで公開されている場合は、それらの変数に適切な値を割り当てます。
- コンポーネントを log_error_services 値にリストして有効にします。
コンポーネントを log_error_services 値で許可するには、既知である必要があります。コンポーネントは、組み込まれている場合、またはロード可能で INSTALL COMPONENT を使用してロードされている場合に認識されます。サーバーの起動時に不明なコンポーネントの名前を指定しようとすると、log_error_services がデフォルト値に設定されます。実行時に不明なコンポーネントを指定しようとするとエラーが発生し、log_error_services 値は変更されません。
ログコンポーネントを無効にするには、log_error_services 値から削除します。次に、コンポーネントがロード可能で、アンロードする場合は、UNINSTALL COMPONENT を使用します。

UNINSTALL COMPONENT を使用して、まだ log_error_services 値に指定されているロード可能コンポーネントをアンロードしようとすると、エラーが発生します。

たとえば、デフォルトのシンク (log_sink_internal) のかわりにシステムログシンク (log_sink_syseventlog) を使用するには、まずシンクコンポーネントをロードしてから、log_error_services 値を変更します:

INSTALL COMPONENT 'file://component_log_sink_syseventlog';
SET GLOBAL log_error_services = 'log_filter_internal; log_sink_syseventlog';

注記

INSTALL COMPONENT を使用してログコンポーネントをロードするために使用する URN は、file://component_という接頭辞が付いたコンポーネント名です。たとえば、log_sink_syseventlog コンポーネントの場合、対応する URN は file://component_log_sink_syseventlog です。

複数のログシンクを構成して、複数の宛先に出力を送信できます。デフォルトシンクに加えて (ではなく) システムログシンクを有効にするには、log_error_services 値を次のように設定します:

SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal; log_sink_syseventlog';

デフォルトのシンクのみを使用してシステムログシンクをアンロードするには、次のステートメントを実行します:

SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal;
UNINSTALL COMPONENT 'file://component_log_sink_syseventlog';

サーバーの起動ごとに有効になるようにログコンポーネントを構成するには、次の手順を使用します:

コンポーネントがロード可能な場合は、INSTALL COMPONENT を使用して実行時にロードします。コンポーネントをロードすると、それが mysql.component システムテーブルに登録され、後続の起動時にサーバーによって自動的にロードされます。
コンポーネント名を含むように、起動時に log_error_services 値を設定します。サーバー my.cnf ファイルで値を設定するか、SET PERSIST を使用して、実行中の MySQL インスタンスの値を設定し、後続のサーバーの再起動に使用する値も保存します。セクション13.7.6.1「変数代入の SET 構文」を参照してください。 my.cnf で設定された値は、次回の再起動時に有効になります。 SET PERSIST を使用して設定された値は、すぐに有効になり、その後の再起動に対して有効になります。

サーバーの起動ごとに、組込みログフィルタおよびシンク (log_filter_internal、log_sink_internal) に加えて JSON ログシンク (log_sink_json) を使用するように構成するとします。 JSON シンクがロードされていない場合は、最初にロードします:

INSTALL COMPONENT 'file://component_log_sink_json';

次に、サーバーの起動時に有効になるように log_error_services を設定します。これは、my.cnf で設定できます:

[mysqld]
log_error_services='log_filter_internal; log_sink_internal; log_sink_json'

または、SET PERSIST を使用して設定できます:

SET PERSIST log_error_services = 'log_filter_internal; log_sink_internal; log_sink_json';

log_error_services で指定されたコンポーネントの順序は、特にフィルタおよびシンクの相対的な順序に関して重要です。次の log_error_services 値について考えてみます:

log_filter_internal; log_sink_1; log_sink_2

この場合、ログイベントは組込みフィルタ、最初のシンク、次に 2 番目のシンクに渡されます。どちらのシンクも、フィルタリングされたログイベントを受信します。

これを次の log_error_services 値と比較します:

log_sink_1; log_filter_internal; log_sink_2

この場合、ログイベントは最初のシンク、次に組み込みフィルタ、次に 2 番目のシンクに渡されます。最初のシンクはフィルタリングされていないイベントを受信します。 2 番目のシンクは、フィルタリングされたイベントを受信します。すべてのログイベントのメッセージを含むログと、ログイベントのサブセットのメッセージのみを含む別のログが必要な場合は、この方法でエラーロギングを構成できます。

注記

有効になっているログコンポーネントにパフォーマンススキーマのサポートを提供するシンクが含まれている場合、エラーログに書き込まれたイベントもパフォーマンススキーマ error_log テーブルに書き込まれます。これにより、SQL クエリーを使用したエラーログの内容の調査が可能になります。現在、従来の形式の log_sink_internal および JSON 形式の log_sink_json シンクでは、この機能がサポートされています。セクション27.12.19.1「error_log テーブル」を参照してください。

PREV HOME UP NEXT