Go to the first, previous, next, last section, table of contents.
A working Posix thread library is needed for the server. On Solaris 2.5
we use SUN PThreads (the native thread support in 2.4 and earlier
versions are not good enough) and on Linux we use LinuxThreads by Xavier
The hard part of porting to a new Unix variant without good native
thread support is probably to port MIT-pthreads. See
Programming POSIX Threads.
The MySQL distribution includes a patched version of
Provenzano's Pthreads from MIT (see
web page). This can be used for some operating systems that do not
have POSIX threads.
It is also possible to use another user level thread package named
FSU Pthreads (see
home page). This implementation is being used for the SCO port.
See the `thr_lock.c' and `thr_alarm.c' programs in the `mysys'
directory for some tests/examples of these problems.
Both the server and the client need a working C++ compiler (we use
and have tried SparcWorks). Another compiler that is known to work is the
To compile only the client use
There is currently no support for only compiling the server. Nor is it
likly to be added unless someone has a good reason for it.
If you want/need to change any `Makefile' or the configure script you must
get Automake and Autoconf. We have used the
All steps needed to remake everything from the most basic files.
/bin/rm -f config.cache
./configure --with-debug --prefix='your installation directory'
# The makefiles generated above need GNU make 3.75 or newer.
# (called gmake below)
gmake clean all install init-db
If you run into problems with a new port, you may have to do some debugging
See section G.1 Debugging a MySQL server.
Note: Before you start debugging
mysqld, first get the test
mysys/thr_lock to work. This
will ensure that your thread installation has even a remote chance to work!
If you are using some functionality that is very new in MySQL,
you can try to run mysqld with the
--skip-new (which will disable all
new, potentially unsafe functionality) or with
disables a lot of optimization that may cause problems.
See section 18.1 What to do if MySQL keeps crashing.
mysqld doesn't want to start, you should check that you don't have
my.cnf file that interferes with your setup!
You can check your
my.cnf arguments with
and avoid using them by starting with
mysqld --no-defaults ....
If you have some very specific problem, you can always try to debug
MySQL. To do this you must configure MySQL with the
--with-debug. You can check whether or not
MySQL was compiled with debugging by doing:
--help. If the
--debug flag is listed with the options then you
have debugging enabled.
mysqladmin ver also lists the
mysqld version as
mysql ... -debug in this case.
If you are using gcc or egcs, the recommended configure line is:
CC=gcc CFLAGS="-O6" CXX=gcc CXXFLAGS="-O6 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-debug
This will avoid problems with the libstdc++ library and with C++ exceptions.
If you can cause the
mysqld server to crash quickly, you can try to
create a trace file of this:
mysqld server with a trace log in `/tmp/mysql.trace'.
The log file will get very BIG.
mysqld --debug --log
or you can start it with
which only prints information with the most interesting tags.
When you configure MySQL for debugging you automatically enable a
lot of extra safety check functions that monitor the health of
If they find something ``unexpected,'' an entry will be written to
safe_mysqld directs to the error log! This also
means that if you are having some unexpected problems with MySQL and
are using a source distribution, the first thing you should do is to
configure MySQL for debugging! (The second thing, of course, is to
send mail to email@example.com and ask for help. Please use the
mysqlbug script for all bug reports or questions regarding the
MySQL version you are using!
On most system you can also start
gdb to get
more information if
gdb versions on Linux you must use
run --one-thread if
you want to be able to debug
mysqld threads. In this case you
can only have one thread active at a time.
If you are using gdb 4.17.x on Linux, you should install a `.gdb' file,
with the following information, in your current directory:
set print sevenbit off
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
handle SIGWAITING nostop noprint
handle SIGLWP nostop noprint
handle SIGPIPE nostop
handle SIGALRM nostop
handle SIGHUP nostop
handle SIGTERM nostop noprint
Here follows an example how to debug mysqld:
shell> gdb /usr/local/libexec/mysqld
back # Do this when mysqld crashes
(until you get some information about local variables)
Include the above output in a mail generated with
mail this to
mysqld hangs you can try to use some system tools like
/usr/proc/bin/pstack to examine where
mysqld has hanged.
mysqld starts to eat up CPU or memory or if it ``hangs'', you
mysqladmin processlist status to find out if someone is
executing some query that takes a long time. It may be a good idea to
mysqladmin -i10 processlist status in some window if you are
experiencing performance problems or problems when new clients can't connect.
mysqld dies or hangs, you should start
mysqld dies again, you can check in the log
file for the query that killed
mysqld. Note that before starting
--log you should check all your tables with
myisamchk. See section 13 Maintaining a MySQL installation.
If you are using a log file,
mysqld --log, you should check the
'hostname' log files, that you can find in the database directory, for
any queries that could cause a problem. Try the command
SELECT statements that takes a long time to ensure that
mysqld are using indexes properly. See section 7.22
EXPLAIN syntax (Get information about a
should also test complicated queries that didn't complete within the
mysql command line tool.
If you find the text
mysqld restarted in the error log file (normally
named `hostname.err') you have probably found a query that causes
mysqld to fail. If this happens you should check all your tables with
myisamchk (see section 13 Maintaining a MySQL installation), and test the queries in the
MySQL log files if someone doesn't work. 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 firstname.lastname@example.org. Links to mail archives are
available at the online MySQL
If you get corrupted tables or if
mysqld always fails after some
update commands, you can test if this bug is reproducible by doing the
Stop the mysqld daemon (with
Check all tables with
myisamchk -s database/*.MYI. Repair any
wrong tables with
myisamchk -r database/table.MYI.
When you have got a crashed table, stop the
Restore the backup.
mysqld server without
Re-execute the commands with
mysql < update-log. The update log
is saved in the MySQL database directory with the name
If the tables are now again corrupted, you have found reproducible bug
ISAM code! FTP the tables and the update log to
ftp://www.mysql.com/pub/mysql/secret and we will fix this as soon as
mysqladmin debug will dump some information about
locks in use, used memory and query usage to the mysql log file. This
may help solve some problems. This command also provides some useful
information even if you haven't compiled MySQL for debugging!
If the problem is that some tables are getting slower and slower you
should try to optimize the table with
OPTIMIZE TABLE or
myisamchk. See section 13 Maintaining a MySQL installation. You should also check the slow
You should also read the OS-specific section in this manual for
problems that may be unique to your environment.
See section 4.11 System-specific issues.
If you are using the Perl
DBI interface, you can turn on
debugging information by using the
trace method or by
DBI_TRACE environment variable.
See section 20.5.2 The
To be able to debug a MySQL client with the integrated debug package,
you should configure MySQL with
See section 4.7.3 Typical
Before running a client, you should set the
shell> export MYSQL_DEBUG
This causes clients to generate a trace file in `/tmp/client.trace'.
If you have problems with your own client code, you should attempt to
connect to the server and run your query using a client that is known to
work. Do this by running
mysql in debugging mode (assuming you
have compiled MySQL with debugging on):
shell> mysql --debug=d:t:O,/tmp/client.trace
This will provide useful information in case you mail a bug report.
See section 2.3 How to report bugs or problems.
If your client crashes at some 'legal' looking code, you should check
that your `mysql.h' include file matches your mysql library file.
A very common mistake is to use an old `mysql.h' file from an old
MySQL installation with new MySQL library.
I have tried to use the RTS thread packages with MySQL but
stumbled on the following problems:
They use old version of a lot of POSIX calls and it is very tedious to
make wrappers for all functions. I am inclined to think that it would
be easier to change the thread libraries to the newest POSIX
Some wrappers are already written. See `mysys/my_pthread.c' for more info.
At least the following should be changed:
pthread_get_specific should use one argument.
sigwait should take two arguments.
A lot of functions (at least
should return the error code on error. Now they return -1 and set
Another problem is that user-level threads use the
ALRM signal and this
aborts a lot of functions (
MySQL should do a retry on interrupt on all of these but it is
not that easy to verify it.
The biggest unsolved problem is the following:
To get thread-level alarms I changed `mysys/thr_alarm.c' to wait between
pthread_cond_timedwait(), but this aborts with error
EINTR. I tried to debug the thread library as to why this happens,
but couldn't find any easy solution.
If someone wants to try MySQL with RTS threads I suggest the
MySQL is very dependent on the thread package used. So when
choosing a good platform for MySQL, the thread package is very
There are at least three types of thread packages:
User threads in a single process. Thread switching is managed with
alarms and the threads library manages all non-thread-safe functions
with locks. Read, write and select operations are usually managed with a
thread-specific select that switches to another thread if the running
threads have to wait for data. If the user thread packages are
integrated in the standard libs (FreeBSD and BSDI threads) the thread
package requires less overhead than thread packages that have to map all
unsafe calls (MIT-pthreads, FSU Pthreads and RTS threads). In some
environments (for example, SCO), all system calls are thread-safe so the
mapping can be done very easily (FSU Pthreads on SCO). Downside: All
mapped calls take a little time and it's quite tricky to be able to
handle all situations. There are usually also some system calls that are
not handled by the thread package (like MIT-pthreads and sockets). Thread
scheduling isn't always optimal.
User threads in separate processes. Thread switching is done by the
kernel and all data are shared between threads. The thread package
manages the standard thread calls to allow sharing data between threads.
LinuxThreads is using this method. Downside: Lots of processes. Thread
creating is slow. If one thread dies the rest are usually left hanging
and you must kill them all before restarting. Thread switching is
Kernel threads. Thread switching is handled by the thread library or the
kernel and is very fast. Everything is done in one process, but on some
ps may show the different threads. If one thread aborts the
whole process aborts. Most system calls are thread-safe and should
require very little overhead. Solaris, HP-UX, AIX and OSF1 have kernel
In some systems kernel threads are managed by integrating user
level threads in the system libraries. In such cases, the thread
switching can only be done by the thread library and the kernel isn't
really ``thread aware''.
Go to the first, previous, next, last section, table of contents.