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.
Beginning with MySQL 4.0.10, you can specify where
mysqld writes the error log with the
--log-error[=
option. If no file_name
]file_name
value is given,
mysqld uses the name
by
default. The server creates the file in the data directory unless
an absolute path name is given to specify a different directory.
(Prior to MySQL 4.0.10, the Windows error log name is
host_name
.errmysql.err
.) If you execute
FLUSH LOGS
, the
error log is renamed with a suffix of -old
and
mysqld creates a new empty log file. (No
renaming occurs if the --log-error
option was not given to mysqld.)
In older MySQL versions on Unix, error log handling was done by
mysqld_safe which redirected the error file to
. You
could change this file name by specifying a
host_name
.err--err-log=
option to mysqld_safe.
file_name
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.
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 will have a source of
MySQL. You cannot disable writing information
to the Windows Event 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) as of MySQL 4.0.19 and 4.1.2. Warning logging
can be disabled using a value of 0. As of MySQL 4.0.21 and 4.1.3,
the value can be greater than 1. If the value is greater than 1,
aborted connections are written to the error log. See
Section A.5.2.11, “Communication Errors and Aborted Connections”.
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.
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.
It seems that if you are using mysqld_safe (whether you specify --log-error= or not), FLUSH LOGS will not rename and recreate the error log, because mysqld_safe does not pass the --log-error= arg to mysqld; rather, it runs mysqld with stderr redirected to the error log file.
Add your own comment.