|
All MySQL versions are tested on many platforms before they are
released. This doesn't mean that there isn't any bugs in
MySQL, but that if there are bugs they are very few and can be
hard to find. If you have a problem, it will always help if you try to
find out exactly what crashes your system as you will have a much better
chance of getting this fixed quickly.
First you should try to find out whether the problem is that the
mysqld daemon dies or whether your problem has to do with your
client. You can check how long your mysqld server has been up by
executing mysqladmin version . If mysqld has died, you may
find the reason for this in the file
`mysql-data-directory/'hostname'.err'.
Since it is very difficult to know why something is crashing, first try to
check whether or not things that work for others crash for you. Please try
the following things:
-
Take down the
mysqld daemon with mysqladmin shutdown , run
isamchk --silent --force */*.ISM on all tables and restart the
mysqld daemon. This will ensure that you are running from a clean
state. 13 Maintaining a MySQL installation.
-
Use
mysqld --log and try to determine from the information in the log
whether or not some specific query kills the server. 95% of all bugs are
related to a particular query! Normally this is one of the last queries in
the log file just before MySQL restarted.
You may be able to verify this using the following procedure:
-
Take down the MySQL daemon (with
mysqladmin shutdown )
-
Make a backup of files in the MySQL database directory.
-
Check the tables with
isamchk -s */*.ISM to verify that all tables
are correct. If any table is corrupted, repair it with
isamchk -r path-to-table.ISM .
-
Remove (or move away) any old log files from the MySQL data directory.
-
Start the server with
safe_mysql --log .
-
If
mysqld now dies, you can test if the problem is a specific
query by restoring the backup and executing mysql <
mysql-log-file . You can of course do the last test in some other
directory than the standard MySQL database directory by
starting another MySQL server with safe_mysqld
--data=path-to-backup-directory .
-
Have you tried the benchmarks? They should test MySQL rather well.
You can also add code that simulates your application! The benchmarks can be
found in the `bench' directory in the source distribution, or, for a
binary distribution, in the `sql-bench' directory under your
MySQL installation directory.
-
Try
fork_test.pl and fork2_test.pl .
-
Check the file `mysql-data-directory/'hostname'.err' for any errors.
-
If you configure MySQL for debugging, it will be much easier to
gather information about possible errors if something goes wrong.
Reconfigure MySQL with the
--with-debug option to
configure and then recompile. G.1 Debugging a MySQL server.
-
Configuring MySQL for debugging causes a safe memory allocator to be
included that can find some errors. It also provides a lot of output about
what is happening.
-
Have you applied the latest patches for your operating system?
-
Use the
--skip-locking option to mysqld . On some systems, the
lockd lock manager does not work properly; the --skip-locking
option tells mysqld not to use external locking. (This means that you
cannot run 2 mysqld servers on the same data and that you must be
careful if you use isamchk , but it may be instructive to try the
option as a test.)
-
Have you tried
mysqladmin -u root processlist when mysqld
appears to be running but not responding? Sometimes mysqld is not
comatose even though you might think so. The problem may be that all
connections are in use, or there may be some internal lock problem.
mysqladmin processlist will usually be able to make a connection even
in these cases, and can provide useful information about the current number
of connections and their status.
-
Run the command
mysqladmin -i 5 status
in a separate window to produce statistics while you run your other queries.
-
Try the following:
-
Start
mysqld from gdb (or another debugger).
-
Run your test scripts.
-
Do
back (or the backtrace command in your debugger) when
mysqld core dumps.
-
Try to simulate your application with a Perl script to force
MySQL to crash or misbehave.
-
Or send a normal bug report. 2.3 How to report bugs or problems. But be even more detailed
than usual. Since MySQL works for many people, it may be that the
crash results from something that exists only on your computer (for example,
an error that is related to your particular system libraries).
-
If you have a problem with table with dynamic length rows and you are
not using
BLOB/TEXT columns (but only VARCHAR columns) you
can try to change all VARCHAR to CHAR with ALTER
TABLE . This will force MySQL to use fixed size rows. Fixed
size rows take a little extra place, but are much more tolerant for
corruption!
The current dynamic row code has been in use at TCX for at least 3
years without any problems, but by nature dynamic length rows are more
prone to errors so it may be a good idea to try if the above helps!
|