MySQL 8.0 Reference Manual Including MySQL NDB Cluster 8.0
In MySQL 8.0, error logging uses the MySQL component architecture described at Section 5.5, “MySQL 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 log filters, see Section 5.4.2.4, “Types of Error Log Filtering”. For instructions specific to the JSON and system log sinks, see Section 5.4.2.7, “Error Logging in JSON Format”, and Section 5.4.2.8, “Error Logging to the System Log”. For additional details about all available log components, see Section 5.5.3, “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 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
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
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
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.
The final component in the
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
option (and, on
Windows, --pid-file
and
--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”.
The log_error_verbosity
and
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)”.
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
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
(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
value.
For a component to be permitted in the
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
. Attempts
to name an unknown component at server startup cause
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
value
remains unchanged.
To disable a log component, remove it from the
log_error_services
value.
Then, if the component is loadable and you also want to
unload it, use UNINSTALL
COMPONENT
.
Attempts to use UNINSTALL
COMPONENT
to unload a loadable component that is
still named in the
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
value:
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
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
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:
If the component is loadable, load it at runtime using
INSTALL COMPONENT
. Loading
the component registers it in the
mysql.component
system table so that the
server loads it automatically for subsequent startups.
Set the 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
, which sets the 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”. A value set in
my.cnf
takes effect at the next
restart. A value set using
SET
PERSIST
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
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 PERSIST log_error_services = 'log_filter_internal; log_sink_internal; log_sink_json';
The order of components named in
log_error_services
is
significant, particularly with respect to the relative order of
filters and sinks. Consider this
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
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.
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
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.19.1, “The error_log Table”.