Spec-Zone .ru
спецификации, руководства, описания, API
|
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.2.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 didn't 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.2.5, "The Slow Query Log".
If you find the text mysqld restarted
in the error log file (normally named hostname.err
) 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 doesn't help and you
can't find anything in the mysql
mail archive, you should report the bug to a MySQL
mailing list. The mailing lists are described at
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.3,
"Server Command Options".
In MySQL 5.6, 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.