Search the MySQL manual:

2.6.2.1 Linux Notes for Binary Distributions

MySQL needs at least Linux Version 2.0.

Warning: We have reports from some MySQL users that they have got serious stability problems with MySQL with Linux kernel 2.2.14. If you are using this kernel you should upgrade to 2.2.19 (or newer) or to a 2.4 kernel. If you have a multi-cpu box, then you should seriously consider using 2.4 as this will give you a significant speed boost.

The binary release is linked with -static, which means you do not normally need to worry about which version of the system libraries you have. You need not install LinuxThreads, either. A program linked with -static is slightly bigger than a dynamically linked program but also slightly faster (3-5%). One problem, however, is that you can't use user-definable functions (UDFs) with a statically linked program. If you are going to write or use UDFs (this is something for C or C++ programmers only), you must compile MySQL yourself, using dynamic linking.

If you are using a libc-based system (instead of a glibc2 system), you will probably get some problems with hostname resolving and getpwnam() with the binary release. (This is because glibc unfortunately depends on some external libraries to resolve hostnames and getpwent(), even when compiled with -static). In this case you probably get the following error message when you run mysql_install_db:

Sorry, the host 'xxxx' could not be looked up

or the following error when you try to run mysqld with the --user option:

getpwnam: No such file or directory

You can solve this problem in one of the following ways:

The Linux-Intel binary and RPM releases of MySQL are configured for the highest possible speed. We are always trying to use the fastest stable compiler available.

MySQL Perl support requires Version Perl 5.004_03 or newer.

On some Linux 2.2 versions, you may get the error Resource temporarily unavailable when you do a lot of new connections to a mysqld server over TCP/IP.

The problem is that Linux has a delay between when you close a TCP/IP socket and until this is actually freed by the system. As there is only room for a finite number of TCP/IP slots, you will get the above error if you try to do too many new TCP/IP connections during a small time, like when you run the MySQL `test-connect' benchmark over TCP/IP.

We have mailed about this problem a couple of times to different Linux mailing lists but have never been able to resolve this properly.

The only known 'fix' to this problem is to use persistent connections in your clients or use sockets, if you are running the database server and clients on the same machine. We hope that the Linux 2.4 kernel will fix this problem in the future.

User Comments

Posted by [name withheld] on Thursday January 30 2003, @10:57am[Delete] [Edit]

> The problem is that Linux has a delay between
> when you close a TCP/IP socket and until this
> is actually freed by the system.

This isn't a Linux problem. The delay between closing
a TCP/IP socket, and freeing it, is part of the
network specification.

Linux should not be changed to make MySQL work,
unless Linux violates a standard. Since Linux
does not seem to be violating the standard, then
instead, you should change MySQL to work correctly.

A suggestion as to how to do that is to use the
SO_REUSEADDR socket option. WARNING! Using this
may violate the TCP/IP standard, so use with
extreme care, and only if you understand why
such a delay exists, and under what conditions it
is safe to bypass this delay.

Posted by Jack Bisson on Monday March 3 2003, @6:05pm[Delete] [Edit]

Can you add the feature ( like Oracle has with the addition off more listenser at different ports ) to have mysql be able to listen on more than one port. I would imagine ( maybe I am way off base ) that many people trying to get through the same door at the same time would cause a bottleneck. If there were other ports that mysql had to connect I would think that this bottleneck could be reduced. Thanks for a great product and the hard work.

Add your own comment.