Pre-General Availability Draft: 2018-03-23
In MySQL 8.0, error logging uses the MySQL component architecture described at Section 5.5, “MySQL Server Components”. 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 the system log and JSON log writers, see Section 126.96.36.199, “Error Logging to the System Log”, and Section 188.8.131.52, “Error Logging in JSON Format”. For additional details about all available log components, see Section 5.5.1, “Error Log Components”.
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 writer components combine to implement the default error logging format.
A loadable writer enables logging to the system log.
A loadable writer enables logging in JSON format.
System variables control which log components to enable and the rules for filtering log events.
variable controls which log components to enable for error
logging. Its value is a list of semicolon-separated components.
Spaces are not significant. Component order is significant
because the server executes components in the order listed.
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
built-in filter component,
log_filter_internal, then through the
built-in log writer component,
log_sink_internal. A filter modifies log
events seen by components named later in the
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.
assigned a value that contains no writer components, no log
output is written from that point.
The combination of
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
The output destination is determined by the
--log-erroroption (and, on Windows,
--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 184.108.40.206, “Default Error Log Destination Configuration”.
To change the set of log components used for error logging, load
components as necessary and modify the
Adding or removing log components is subject to these
For a component to be permitted in the
log_error_servicesvalue, 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. Attempts to name an unknown component at server startup cause
log_error_servicesto be set to its default value. Attempts to name an unknown component at runtime produce an error and the
log_error_servicesvalue remains unchanged.
For example, to use the system log writer
log_sink_syseventlog) instead of the default
log_sink_internal), first load the
writer component, then modify the
INSTALL COMPONENT 'file://component_log_sink_syseventlog'; SET GLOBAL log_error_services = 'log_filter_internal; log_sink_syseventlog';
The URN to use for loading a log component with
INSTALL COMPONENT is the
component name prefixed with
file://component_. For example, for the
log_sink_syseventlog component, the
corresponding URN is
It is possible to configure multiple log writers to send output
to multiple destinations. To enable the system log writer in
addition to (rather than instead of) the default writer, set the
log_error_services value like
SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal; log_sink_syseventlog';
To revert to using only the default writer and unload the system log writer, 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:
If the component is loadable, load it using
INSTALL COMPONENT. Loading the component registers it in the
mysql.componentsystem table so that the server loads it automatically for subsequent startups.
log_error_servicesvalue at startup to include the component name. Set the value either in the server
my.cnffile, or use
SET PERSIST, which sets the value for the running MySQL instance and also saves the value to be used for subsequent server restarts; see Section 220.127.116.11, “SET Syntax for Variable Assignment”. A value set in
my.cnftakes effect at the next restart. A value set using
SET PERSISTtakes effect immediately, and for subsequent restarts.
Suppose that you want to configure, for every server startup,
use of the JSON log writer (
addition to the built-in log filter and writer
log_sink_internal). First load the JSON
writer if it is not loaded:
INSTALL COMPONENT 'file://component_log_sink_json';
take effect at server startup. You can set it in
[mysqld] log_error_services='log_filter_internal; log_sink_internal; log_sink_json'
Or you can set it using
SET PERSIST log_error_services = 'log_filter_internal; log_sink_internal; log_sink_json';
log_filter_internal; log_sink_1; log_sink_2
In this case, log events pass to the built-in filter, then to the first writer, then to the second writer. Both writers receive filtered log events.
Compare that to this
log_sink_1; log_filter_internal; log_sink_2
In this case, log events pass to the first writer, then to the built-in filter, then to the second writer. The first writer receives unfiltered events. The second writer receives filtered events. You might configure error logging this way if you want one log that contains messages for all log events, and another containing messages only for a subset of log events.