Error Log

The error log contains a record of critical errors that occurred during the server's operation, table corruption, start and stop information.

SQL errors can also be logged in a separate file using the SQL_ERROR_LOG plugin.

Configuring the Error Log Output Destination

MariaDB always writes its error log, but the destination is configurable.

Writing the Error Log to a File

To configure the error log to be written to a file, you can set the system variable. You can configure a specific file name. However, if a specific file name is not configured, the log will be written to the ${hostname}.err file in the directory by default.

The system variable can be set in a server in an prior to starting up the server. For example, to write the error log to the default ${hostname}.err file, you could configure the following:

If you configure a specific file name as the system variable, and if it is not an absolute path, then it will be relative to the directory. For example, if you configured the following, then the error log would be written to mariadb.err in the directory:

If it is a relative path, then the is relative to the directory.

However, the system variable can also be an absolute path:

Another way to configure the error log file name is to set the option, which configures MariaDB to use a common prefix for all log files (e.g. , , error log, , etc.). The error log file name will be built by adding a .err extension to this prefix. For example, if you configured the following, then the error log would still be written to mariadb.err in the directory:

The cannot be an absolute path. The log file name is relative to the directory.

Writing the Error Log to Stderr on Unix

On Unix, if the system variable is not set, errors are written to stderr, which usually means that the log messages are output to the terminal that started mariadbd.

If the system variable was set in an or on the command-line, it can still be unset by specifying --skip-log-error.

Writing the Error Log to Syslog on Unix

On Unix, the error log can also be redirected to the . How this is done depends on how you MariaDB.

Syslog with mariadbd-safe

If you MariaDB with , the error log can be redirected to the syslog. See for more information.

Syslog with Systemd

If you MariaDB with , the error log can also be redirected to the syslog. See for more information.

also has its own logging system called the journal, and some errors may get logged there instead. See for more information.

Writing the Error Log to Console on Windows

On Windows, if the option is specified, and if the system variable is not used, errors are written to the console. If both options are specified, the last option takes precedence.

Writing the Error Log to the Windows Event Viewer

On Windows, error log messages are also written to the Windows Event Viewer. You can find MariaDB's error log messages by browsing Windows Logs, then selecting Application or Application Log, depending on the Windows version.

You can find MariaDB's error log messages by searching for the Source MariaDB (prior to , this was MySQL).

Finding the Error Log

To find where the error log is stored, one can find the options used for the error log with:

or (from )

or

If the above don't help, check also if your system is set to , in which case you need to use to access it.

Configuring the Error Log Verbosity

The default value of the system variable is 2.

The system variable can be used to configure the verbosity of the error log. It can be changed dynamically with . For example:

It can also be set either on the command-line or in a server in an prior to starting up the server. For example:

Some of the warnings included in each verbosity level are described below.

The system variable only has an effect on some log messages. Some log messages are always written to the error log, regardless of the error log verbosity. For example, most warnings from the InnoDB storage engine are not affected by . For a complete list of log messages affected by , see the description of the system variable.

Verbosity Level 0

If is 0, many optional warnings will not be logged. However, this does not prevent all warnings from being logged, because there are certain core warnings that will always be written to the error log. For example:

• If is disabled, and if DDL is performed on a table that triggers a , InnoDB logs a warning:

However, if is enabled, the same message will be logged as an error.

Verbosity Level 1

Default until . If is 1, many types of warnings are logged. Some useful warnings are:

• Replication-related messages:

• Messages related to DNS lookup failures:

• Messages related to the :

• Messages related to :

Frequent warnings about can cause the error log to grow very large. MariaDB will automatically detect frequent duplicate warnings about . After 10 identical warnings are detected, MariaDB will prevent that same warning from being written to the error log again for the next 5 minutes.

Verbosity Level 2

Default from . If is 2, a couple other different kinds of warnings are printed. For example:

• Messages related to access denied errors:

• Messages related to connections that are aborted due to errors or timeouts:

• Messages related to table handler errors:

• Messages related to the files used to :

  • Either the default master.info file or the file that is configured by the option.

  • Either the default relay-log.info file or the file that is configured by the system variable.

• Messages about a master's :

Verbosity Level 3

If is 3, a couple other different kinds of warnings are printed. For example:

• Messages related to old-style language options:

• Messages related to :

Verbosity Level 4

If is 4, a couple other different kinds of warnings are printed. For example:

• Messages related to killed connections:

• Messages related to all closed connections:

• Messages related to released connections, such as when a transaction is committed and is set to RELEASE:

Verbosity Level 9

If is 9, some very verbose warnings are printed. For example:

• Messages about initializing plugins:

MySQL's log_error_verbosity

MariaDB does not support the system variable added in MySQL 5.7.

Format

The error log begins with a line indicating where the data is being read from, for example:

Then, each item (note, warning or error) consists of a single line, containing the date (yyyy-mm-dd) and time, the thread ID, followed by the type of error (Note, Warning or Error) and the error message, for example:

Until , the format only consisted of the date (yymmdd) and time, followed by the type of error (Note, Warning or Error) and the error message, for example:

The first item will always contain the source revision, a unique server id (from , , , , , , , ) and the process_id, for example:

or

Rotating the Error Log on Unix and Linux

Unix and Linux distributions offer the utility, which makes it very easy to rotate log files. See for more information on how to use this utility to rotate the error log.

Error Messages File

Many error messages are read from an error message file that contains localized error messages. If the server can't find this file when it starts up, you might see errors like the following:

If this error is occurring because the file is in a custom location, you can configure this location by setting the system variable either on the command-line or in a server in an prior to starting up the server:

If you want to use a different locale for error messages, you can also set the system variable:

See for more information.

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}