Documentation Home
MySQL 5.7 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 33.9Mb
PDF (A4) - 34.0Mb
PDF (RPM) - 33.2Mb
EPUB - 8.5Mb
HTML Download (TGZ) - 8.2Mb
HTML Download (Zip) - 8.2Mb
HTML Download (RPM) - 7.1Mb
Eclipse Doc Plugin (TGZ) - 9.0Mb
Eclipse Doc Plugin (Zip) - 11.1Mb
Man Pages (TGZ) - 219.4Kb
Man Pages (Zip) - 322.3Kb
Info (Gzip) - 3.2Mb
Info (Zip) - 3.2Mb
Excerpts from this Manual

5.2.2 The Error Log

The error log contains information indicating when mysqld was started and stopped and also any critical errors that occur while the server is running. If mysqld notices a table that needs to be automatically checked or repaired, it writes a message to the error log.

On some operating systems, the error log contains a stack trace if mysqld dies. The trace can be used to determine where mysqld died. See Section 25.5, “Debugging and Porting MySQL”.

If mysqld_safe is used to start mysqld and mysqld dies unexpectedly, mysqld_safe notices this, restarts mysqld, and writes a restarted mysqld message to the error log.

In the following discussion, console means stderr, the standard error output; this is your terminal or console window unless the standard error output has been redirected.

On Windows, the --log-error and --console options both affect error logging:

  • Without --log-error, mysqld writes error messages to host_name.err in the data directory.

  • With --log-error[=file_name], mysqld writes error messages to an error log file. The server uses the named file if present, creating it in the data directory unless an absolute path name is given to specify a different directory. If no file is named, the default name is host_name.err in the data directory.

  • With --console, mysqld writes error messages to the console. --log-error, if given, is ignored and has no effect. If both options are present, their order does not matter: --console takes precedence and error messages go to the console. (In MySQL 5.5 and 5.6, the precedence is reversed: --log-error causes --console to be ignored.)

In addition, on Windows, the server by default writes events and error messages to the Windows Event Log within the Application log. Entries marked as Error, Warning, and Note are written to the Event Log, but not informational messages such as information statements from individual storage engines. These log entries have a source of MySQL. As of MySQL 5.7.5, writing information to the Windows Event Log can be controlled using the log_syslog system variable, as described later.

On Unix and Unix-like systems, mysqld writes error log messages as follows:

  • Without --log-error, mysqld writes error messages to the console.

  • With --log-error[=file_name], mysqld writes error messages to an error log file. The server uses the named file if present, creating it in the data directory unless an absolute path name is given to specify a different directory. If no file is named, the default name is host_name.err in the data directory.

    Note

    It is common for Yum or APT package installations to configure the error log location to be under /var/log with an entry like log-error=/var/log/mysqld.log in a server configuration file; removing the filename from the entry reverts the error log location back to its default setting, which is the data directory.

At runtime, if the server writes error messages to the console, it sets the log_error system variable to stderr. Otherwise, log_error indicates the error log file name. In particular, on Windows, --console overrides use of an error log file and sends error messages to the console, so the server sets log_error to stderr. This occurs even if --log-error is also given.

If you specify --log-error in an option file in a [mysqld], [server], or [mysqld_safe] section, mysqld_safe will find and use the option.

Using Syslog for the Error Log

On Unix and Unix-like systems, it is possible to write the error log to syslog. To control logging to syslog in MySQL 5.7.5 or later, use these system variables:

  • log_syslog: Enable this variable to send the error log to syslog. In this case, the following system variables can also be used for finer control.

  • log_syslog_facility: The default facility for syslog messages is daemon. Set this variable to specify a different facility.

  • log_syslog_include_pid: Whether to include the server process ID in each line of syslog output.

  • log_syslog_tag: This variable defines a tag to add to the server identifier (mysqld) in syslog messages. If defined, the tag is appended to the identifier with a leading hyphen.

Before MySQL 5.7.5, control of output to syslog is available only on Unix and Unix-like systems and is handled by mysqld_safe, which captures server error output and passes it to syslog. (On Windows, logging to the Event Log is enabled by default and cannot be disabled.) mysqld_safe has three error-logging options, --syslog, --skip-syslog, and --log-error. The default with no logging options or with --skip-syslog is to use the default log file. To explicitly specify use of an error log file, specify --log-error=file_name to mysqld_safe, and mysqld_safe will arrange for mysqld to write messages to a log file. To use syslog instead, specify the --syslog option. For syslog output, a tag can be specified with --syslog-tag=tag_val; this is appended to the mysqld server identifier with a leading hyphen.

Note

As of MySQL 5.7.5, using mysqld_safe for syslog error logging is deprecated; you should use the server system variables instead.

Error Log Verbosity

As of MySQL 5.7.2, the log_error_verbosity system variable controls verbosity of the server in writing error, warning, and note messages to the error log. Permitted values are 1 (errors only), 2 (errors and warnings), 3 (errors, warnings, and notes), with a default of 3. If the value is greater than 2, aborted connections are written to the error log, and access-denied errors for new connection attempts are written. See Section B.5.2.11, “Communication Errors and Aborted Connections”.

Before MySQL 5.7.2, the log_warnings system variable can be used to control warning logging to the error log. The default value is enabled (1). Warning logging can be disabled using a value of 0.

Error Log Message Format

As of MySQL 5.7.2, the log_timestamps system variable controls the timestamp time zone of messages written to the error log (as well as to general query log and slow query log files). Permitted values are UTC (the default) and SYSTEM (local system time zone). Before MySQL 5.7.2, messages use the local system time zone.

As of MySQL 5.7.2, the ID included in error log messages is that of the thread within mysqld responsible for writing the message. This indicates which part of the server produced the message, and is consistent with general query log and slow query log messages, which include the connection thread ID. Before MySQL 5.7.2, the ID in error log messages is that of the mysqld process ID.

Flushing the Error Log File

If you flush the logs using FLUSH LOGS or mysqladmin flush-logs and mysqld is writing the error log to a file (for example, if it was started with the --log-error option), the server closes and reopens the log file. To rename the file, do so manually before flushing. Then flushing the logs reopens a new file with the original file name. For example, you can rename the file and create a new one using the following commands:

shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory

On Windows, use rename rather than mv.

No error log renaming occurs when the logs are flushed if the server is not writing to a named file.


User Comments
  Posted by Jonathan Lampe on September 23, 2004
I did some testing with MySQL 4.0.21 this morning. Here's a typical snippet from my "hostname.err" file. To generate this, I did a "NET START MySQL", connected with one session and ran a 2000-entry query, and then did a "NET STOP MySQL" while the query was still returning data.

MySql: ready for connections.
Version: '4.0.21-nt-log' socket: '' port: 3306 Source distribution
040923 10:00:00 MySql: Normal shutdown
040923 10:00:01 MySql: Forcing close of thread 1 user: 'root'
040923 10:00:01 InnoDB: Starting shutdown...
040923 10:00:03 InnoDB: Shutdown completed
040923 10:00:03 MySql: Shutdown Complete

The Windows Application Event Log recorded 3 messages at the same time. All of the messages corresponded with the entries prefixed with the "MySQL:" entries in the hostname.err file. (OK)

However, all 3 messages were logged as ERRORS; this designation is misleading. If anything, the "Normal Shutdown" and "Shutdown Complete" messages should have been logged as INFORMATION and the "Forcing close of thread..." message should have been logged as a WARNING.

Also, it is important to note that the MySQL service startup was NOT LOGGED in the Event Log.

Long story short, if you are a Windows user, it is probably still best (as of 4.0.21) to stick with your existing "parse-the-.err" script rather than rely on the Windows Event Log if you're interested in MySQL service starts, stops and abnormal events.
Sign Up Login You must be logged in to post a comment.