Rechercher dans le manuel MySQL
29.5.1.6 Using Server Logs to Find Causes of Errors in mysqld
Note that before starting mysqld with the general query log enabled, you should check all your tables with myisamchk. See Chapter 5, MySQL Server Administration.
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.
host_name
.log
You can also try the command
EXPLAIN
on all
SELECT
statements that takes a
long time to ensure that mysqld is using
indexes properly. See Section 13.8.2, “EXPLAIN Syntax”.
You can find the queries that take a long time to execute by starting mysqld with the slow query log enabled. See Section 5.4.5, “The Slow Query Log”.
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”.
host_name
.err
If you have started mysqld with
--myisam-recover-options
, 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 hostname.err
file
'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.7, “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.
It is not a good sign if mysqld did die
unexpectedly, but in this case, you should not investigate the
Checking table...
messages, but instead try
to find out why mysqld died.
Document created the 26/06/2006, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/mysql-rf-using-log-files.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
References
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.