#### 5.4.2.1 Error Log Configuration

 In MySQL 8.0, error logging uses the MySQL component architecture described at [Section 5.5, “MySQL Components”](components.html). The error log subsystem consists of components that perform log event filtering and writing, as well as a system variable that configures which components to enable to achieve the desired logging result.

 This section discusses how to select components for error logging. For instructions specific to log filters, see [Section 5.4.2.4, “Types of Error Log Filtering”](error-log-filtering.html). For instructions specific to the JSON and system log sinks, see [Section 5.4.2.7, “Error Logging in JSON Format”](error-log-json.html), and [Section 5.4.2.8, “Error Logging to the System Log”](error-log-syslog.html). For additional details about all available log components, see [Section 5.5.3, “Error Log Components”](error-log-components.html).

 Component-based error logging offers these features:

* Log events can be filtered by filter components to affect the information available for writing.

* Log events are output by sink (writer) components. Multiple sink components can be enabled, to write error log output to multiple destinations.

* Built-in filter and sink components combine to implement the default error log format.

* A loadable sink enables logging in JSON format.

* A loadable sink enables logging to the system log.

* System variables control which log components to enable and how each component operates.

 The [`log_error_services`](server-system-variables.html#sysvar_log_error_services) system variable controls which log components to enable for error logging. The variable may contain a list with 0, 1, or many elements. In the latter case, elements may be delimited by semicolon or (as of MySQL 8.0.12) comma, optionally followed by space. A given setting cannot use both semicolon and comma separators. Component order is significant because the server executes components in the order listed.

 By default, [`log_error_services`](server-system-variables.html#sysvar_log_error_services) has this value:

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

 That value indicates that log events first pass through the `log_filter_internal` filter component, then through the `log_sink_internal` sink component, both of which are built in. A filter modifies log events seen by components named later in the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value. A sink is a destination for log events. Typically, a sink processes log events into log messages that have a particular format and writes these messages to its associated output, such as a file or the system log.

Note

 The final component in the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value cannot be a filter. This is an error because any changes it has on events would have no effect on output:

```
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'
```

 To correct the problem, include a sink at the end of the value:

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

 The combination of `log_filter_internal` and `log_sink_internal` implements the default error log filtering and output behavior. The action of these components is affected by other server options and system variables:

* The output destination is determined by the [`--log-error`](server-options.html#option_mysqld_log-error) option (and, on Windows, [`--pid-file`](server-system-variables.html#sysvar_pid_file) and [`--console`](server-options.html#option_mysqld_console)). These determine whether to write error messages to the console or a file and, if to a file, the error log file name. See [Section 5.4.2.2, “Default Error Log Destination Configuration”](error-log-destination-configuration.html).

* The [`log_error_verbosity`](server-system-variables.html#sysvar_log_error_verbosity) and [`log_error_suppression_list`](server-system-variables.html#sysvar_log_error_suppression_list) system variables affect which types of log events `log_filter_internal` permits or suppresses. See [Section 5.4.2.5, “Priority-Based Error Log Filtering (log\_filter\_internal)”](error-log-priority-based-filtering.html).

 To change the set of log components used for error logging, load components as necessary, perform any component-specific configuration, and modify the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value. Adding or removing log components is subject to these constraints:

* To add a log component to the list of enabled components:

  * Load the component using [`INSTALL COMPONENT`](install-component.html) (unless it is built in or already loaded).

  * If the component exposes any system variables that must be set for component initialization to succeed, assign those variables appropriate values.

  * Enable the component by listing it in the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value.

* For a component to be permitted in the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value, it must be known. A component is known if it is built in, or if it is loadable and has been loaded using [`INSTALL COMPONENT`](install-component.html). Attempts to name an unknown component at server startup cause [`log_error_services`](server-system-variables.html#sysvar_log_error_services) to be set to its default value. Attempts to name an unknown component at runtime produce an error and the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value remains unchanged.

* To disable a log component, remove it from the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value. Then, if the component is loadable and you also want to unload it, use [`UNINSTALL COMPONENT`](uninstall-component.html).

   Attempts to use [`UNINSTALL COMPONENT`](uninstall-component.html) to unload a loadable component that is still named in the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value produce an error.

 For example, to use the system log sink (`log_sink_syseventlog`) instead of the default sink (`log_sink_internal`), first load the sink component, then modify the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value:

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

Note

 The URN to use for loading a log component with [`INSTALL COMPONENT`](install-component.html) is the component name prefixed with `file://component_`. For example, for the `log_sink_syseventlog` component, the corresponding URN is `file://component_log_sink_syseventlog`.

 It is possible to configure multiple log sinks, which enables sending output to multiple destinations. To enable the system log sink in addition to (rather than instead of) the default sink, set the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value like this:

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

 To revert to using only the default sink and unload the system log sink, execute these statements:

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

 To configure a log component to be enabled at each server startup, use this procedure:

1. If the component is loadable, load it at runtime using [`INSTALL COMPONENT`](install-component.html). Loading the component registers it in the `mysql.component` system table so that the server loads it automatically for subsequent startups.

2. Set the [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value at startup to include the component name. Set the value either in the server `my.cnf` file, or use [`SET PERSIST`](set-variable.html), which sets a value for the running MySQL instance and also saves the value to be used for subsequent server restarts; see [Section 13.7.6.1, “SET Syntax for Variable Assignment”](set-variable.html). A value set in `my.cnf` takes effect at the next restart. A value set using [`SET PERSIST`](set-variable.html) takes effect immediately, and for subsequent restarts.

 Suppose that you want to configure, for every server startup, use of the JSON log sink (`log_sink_json`) in addition to the built-in log filter and sink (`log_filter_internal`, `log_sink_internal`). First load the JSON sink if it is not loaded:

```
INSTALL COMPONENT 'file://component_log_sink_json';
```

 Then set [`log_error_services`](server-system-variables.html#sysvar_log_error_services) to take effect at server startup. You can set it in `my.cnf`:

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

 Or you can set it using [`SET PERSIST`](set-variable.html):

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

 The order of components named in [`log_error_services`](server-system-variables.html#sysvar_log_error_services) is significant, particularly with respect to the relative order of filters and sinks. Consider this [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value:

```
log_filter_internal; log_sink_1; log_sink_2
```

 In this case, log events pass to the built-in filter, then to the first sink, then to the second sink. Both sinks receive the filtered log events.

 Compare that to this [`log_error_services`](server-system-variables.html#sysvar_log_error_services) value:

```
log_sink_1; log_filter_internal; log_sink_2
```

 In this case, log events pass to the first sink, then to the built-in filter, then to the second sink. The first sink receives unfiltered events. The second sink receives filtered events. You might configure error logging this way if you want one log that contains messages for all log events, and another log that contains messages only for a subset of log events.

Note

 If the enabled log components include a sink that provides Performance Schema support, events written to the error log are also written to the Performance Schema [`error_log`](performance-schema-error-log-table.html) table. This enables examining error log contents using SQL queries. Currently, the traditional-format `log_sink_internal` and JSON-format `log_sink_json` sinks support this capability. See [Section 27.12.21.1, “The error\_log Table”](performance-schema-error-log-table.html).

