22.214.171.124 Using Server Logs to Find Causes of Errors in mysqld
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, report a bug, see Section 1.7, “How to Report Bugs or Problems”.
If you have started mysqld with the
myisam_recover_options system variable set, MySQL 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 followed by
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”.
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.