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 MySQL Internals: Porting to Other Systems.
You can specify where mysqld writes the error
log with the
--log-error[=
option. If the option is given with no
file_name]file_name value,
mysqld uses the name
host_name.err
If you do not specify --log-error,
or (on Windows) if you use the
--console option, errors are
written to stderr, the standard error output.
Usually this is your terminal.
On Windows, error output is always written to the error log if
--console is not given.
In addition, on Windows, events and error messages are written to
the Windows Event Log within the Application log. Entries marked
as Warning and Note are
written to the Event Log, but informational messages (such as
information statements from individual storage engines) are not
copied to the Event Log. The log entries have a source of
MySQL. You cannot disable writing information
to the Windows Event Log.
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 effect is
version dependent:
As of MySQL 5.1.51, the server closes and reopens the log file. To rename the file, you can 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>
mvshell>host_name.errhost_name.err-oldmysqladmin flush-logsshell>mvhost_name.err-oldbackup-directoryOn Windows, use rename rather than mv.
Prior to MySQL 5.1.51, the server renames the current log file with the suffix
-old, then creates a new empty log file. Be aware that a second log-flushing operation thus causes the original error log file to be lost unless you save it under a different name. On Windows, you cannot rename the error log while the server has it open before MySQL 5.1.51. To avoid a restart, flush the logs first to cause the server to rename the original file and create a new one, then save the renamed file. That also works on Unix, or you can use the commands shown earlier.
No error log renaming occurs when the logs are flushed in any case if the server is not writing to a named file.
If you use mysqld_safe to start
mysqld, mysqld_safe arranges
for mysqld to write error messages to a log
file or (as of MySQL 5.1.20) to syslog:
Before 5.1.20, mysqld_safe behavior is to log to a file, using the default error log file if the
--log-erroroption is not given to mysqld_safe. Otherwise, mysqld_safe uses the file name specified using--log-error=.file_nameFrom 5.1.20 on, mysqld_safe has two additional error-logging options,
--syslogand--skip-syslog.In 5.1.21 and up, the default with no logging options is
--skip-syslog, which is compatible with the default behavior of writing an error log file for releases prior to 5.1.20. To explicitly specify use of an error log file, specify--log-error=to mysqld_safe, and mysqld_safe will arrange for mysqld to write messages to a log file. To usefile_namesysloginstead, specify the--syslogoption.In 5.1.20 only, the following conditions apply: 1) The default is to use
syslog, which is not compatible with releases prior to 5.1.20. 2) Logging tosyslogmay fail to operate correctly in some cases; if so, use--skip-syslogor--log-error.For logging to
syslog, messages from mysqld_safe and mysqld are written with a tag ofmysqld_safeandmysqld, respectively. As of MySQL 5.1.21, to specify a suffix for the tag, use--syslog-tag=, which modifies the tags to betagmysqld_safe-andtagmysqld-.tag
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.
If mysqld_safe is used to start
mysqld and mysqld dies
unexpectedly, mysqld_safe notices that it needs
to restart mysqld and writes a
restarted mysqld message to the error log.
The --log-warnings option or
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. If the value is greater than 1, aborted connections
are written to the error log. See
Section C.5.2.11, “Communication Errors and Aborted Connections”.
User Comments
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.
Add your own comment.