MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 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「エラーログコンポーネント」 を参照してください。

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

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

エラーロギングに使用されるログコンポーネントのセットを変更するには、必要に応じてコンポーネントをロードし、コンポーネント固有の構成を実行して、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';

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

  1. コンポーネントがロード可能な場合は、INSTALL COMPONENT を使用して実行時にロードします。 コンポーネントをロードすると、それが mysql.component システムテーブルに登録され、後続の起動時にサーバーによって自動的にロードされます。

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

サーバーの起動ごとに、組込みログフィルタおよびシンク (log_filter_internallog_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 テーブル」を参照してください。