Oracle 5.0 Reference Manual page 2982

Each MySQL version is tested on many platforms before it is released. This does not mean that there
are no bugs in MySQL, but if there are bugs, they should be very few and can be hard to find. If you
have a problem, it always helps if you try to find out exactly what crashes your system, because you
have a much better chance of getting the problem fixed quickly.
First, you should try to find out whether the problem is that the
problem has to do with your client. You can check how long your
executing
mysqladmin
looking in the server's error log. See
On some systems, you can find in the error log a stack trace of where
resolve with the
resolve_stack_dump
Note that the variable values written in the error log may not always be 100% correct.
Many server crashes are caused by corrupted data files or index files. MySQL updates the files on disk
with the system call after every SQL statement and before the client is notified about the
write()
result. (This is not true if you are running with
are written but not index files.) This means that data file contents are safe even if
because the operating system ensures that the unflushed data is written to disk. You can force MySQL
to flush everything to disk after every SQL statement by starting
option.
The preceding means that normally you should not get corrupted tables unless one of the following
happens:
• The MySQL server or the server host was killed in the middle of an update.
• You have found a bug in
• Some external program is manipulating data files or index files at the same time as
locking the table properly.
• You are running many
support good file system locks (normally handled by the
multiple servers with external locking disabled.
• You have a crashed data file or index file that contains very corrupt data that confused mysqld.
• You have found a bug in the data storage code. This isn't likely, but it is at least possible. In this
case, you can try to change the storage engine to another engine by using
repaired copy of the table.
Because it is very difficult to know why something is crashing, first try to check whether things that work
for others crash for you. Please try the following things:
• Stop the server with
mysqld
from the data directory to check all
*.MYI
are running from a clean state. See
• Start with the general query log enabled (see
mysqld
Then try to determine from the information written to the log whether some specific query kills the
server. About 95% of all bugs are related to a particular query. Normally, this is one of the last
queries in the log file just before the server restarts. See
If you can repeatedly kill MySQL with a specific query, even when you have checked all tables just
before issuing it, then you have been able to locate the bug and should submit a bug report for it.
See Section 1.7, "How to Report Bugs or
• Try to make a test case that we can use to repeat the problem. See
Other Systems.
• Try running the tests in the
"The MySQL Test Suite". They should test MySQL rather well. You can also add code to the
Administration-Related Issues
version. If has died and restarted, you may find the reason by
mysqld
Section 5.2.1, "The Error
program. See
--delay-key-write
that caused it to die in the middle of an update.
mysqld
servers using the same data directory on a system that does not
mysqld
shutdown, run
mysqladmin
MyISAM
Chapter 5, MySQL Server
Problems".
directory and the MySQL benchmarks. See
mysql-test
2962
server dies or whether your
mysqld
server has been up by
mysqld
Log".
mysqld
MySQL Internals: Porting to Other
[406], in which case data files
with the
mysqld
lock manager), or you are running
lockd
myisamchk --silent --force */
tables, and restart mysqld. This ensures that you
Administration.
Section 5.2.2, "The General Query
Section 5.2.2, "The General Query
MySQL Internals: Porting to
died that you can
Systems.
crashes,
mysqld
[408]
--flush
without
mysqld
on a
ALTER TABLE
Log").
Log".
Section 21.1.2,