The error log file 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 Using a Stack Trace.
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.
You can specify where mysqld stores the error
log file with the
--log-error[=
option. If no file_name]file_name value is
given, mysqld uses the name
and writes the file in the data directory. If you execute
host_name.errFLUSH LOGS, the error log is renamed with the
suffix -old and mysqld
creates a new empty log file. (No renaming occurs if the
--log-error option was not given.)
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
.err file if --console is
not given.
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.
Aborted connections are not logged to the error log unless the
value is greater than 1. See
Section B.1.2.10, “Communication Errors and Aborted Connections”.

User Comments
How about some doc about how to toggle messages to the Windows Event Log (i.e. MySQL 4.0.21) on and off?
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.