If mysqld dies or hangs, you should start mysqld with the general query log enabled. See Section 5.4.3, “The General Query Log”. When mysqld dies again, you can examine the end of the log file for the query that killed mysqld.
If you use the default general query log file, the log is
stored in the database directory as
In most cases it is the last query in the log file that killed
mysqld, but if possible you should verify
this by restarting mysqld and executing the
found query from the mysql command-line
tools. If this works, you should also test all complicated
queries that did not complete.
If you find the text
mysqld restarted in
the error log (normally a file named
you probably have found a query that causes
mysqld to fail. If this happens, you should
check all your tables with myisamchk (see
Chapter 5, MySQL Server Administration), and test the queries
in the MySQL log files to see whether one fails. If you find
such a query, try first upgrading to the newest MySQL version.
If this does not help and you cannot find anything in the
mysql mail archive, you should report the
bug to a MySQL mailing list. The mailing lists are described
at http://lists.mysql.com/, which also has
links to online list archives.
If you have started mysqld with
automatically checks and tries to repair
MyISAM tables if they are marked as 'not
closed properly' or 'crashed'. If this happens, MySQL writes
an entry in the
'Warning: Checking table ...' which is
Warning: Repairing table if the
table needs to be repaired. If you get a lot of these errors,
without mysqld having died unexpectedly
just before, then something is wrong and needs to be
investigated further. See Section 5.1.6, “Server Command Options”.
As of MySQL 5.5.3, when the server detects
MyISAM table corruption, it writes
additional information to the error log, such as the name and
line number of the source file, and the list of threads
accessing the table. Example:
Got an error from
thread_id=1, mi_dynrec.c:368. This is useful
information to include in bug reports.