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.
          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 larger than a dynamically
          linked program, but also slightly faster (3–5%).
          However, one problem with a statically linked program is that
          you can't use user-defined functions (UDFs). 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.
        
          A known issue with binary distributions is that on older Linux
          systems that use libc (such as Red Hat 4.x
          or Slackware), you get some (nonfatal) issues with host name
          resolution. If your system uses libc rather
          than glibc2, you probably will encounter
          some difficulties with host name resolution and
          getpwnam(). This happens because
          glibc (unfortunately) depends on some
          external libraries to implement host name resolution and
          getpwent(), even when compiled with
          -static. These problems manifest themselves
          in two ways:
        
You may see the following error message when you run mysql_install_db:
Sorry, the host 'xxxx' could not be looked up
              You can deal with this by executing
              mysql_install_db --force, which does
              not execute the resolveip test in
              mysql_install_db. The downside is that
              you cannot use host names in the grant tables: except for
              localhost, you must use IP numbers
              instead. If you are using an old version of MySQL that
              does not support --force, you must
              manually remove the resolveip test in
              mysql_install_db using a text editor.
            
              You also may see the following error when you try to run
              mysqld with the
              --user option:
            
getpwnam: No such file or directory
              To work around this problem, start
              mysqld by using the
              su command rather than by specifying
              the --user option. This
              causes the system itself to change the user ID of the
              mysqld process so that
              mysqld need not do so.
            
          Another solution, which solves both problems, is not to use a
          binary distribution. Obtain a MySQL source distribution (in
          RPM or tar.gz format) and install that
          instead.
        
          On some Linux 2.2 versions, you may get the error
          Resource temporarily unavailable when
          clients make a great many new connections to a
          mysqld server over TCP/IP. The problem is
          that Linux has a delay between the time that you close a
          TCP/IP socket and the time that the system actually frees it.
          There is room for only a finite number of TCP/IP slots, so you
          encounter the resource-unavailable error if clients attempt
          too many new TCP/IP connections over a short period of time.
          For example, you may see the error when you run the MySQL
          test-connect benchmark over TCP/IP.
        
We have inquired about this problem a few times on different Linux mailing lists but have never been able to find a suitable resolution. The only known “fix” is for clients to use persistent connections, or, if you are running the database server and clients on the same machine, to use Unix socket file connections rather than TCP/IP connections.

User Comments
> 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.
Actually, it sounds like a lot of sockets in the TIME_WAIT state, which can last several minutes. This is a normal and important part of a socket's lifecycle. They only way to bypass it is for the server to set the SO_LINGER option, with a timeout value of zero. This forces the socket to reset when closed and avoids the TIME_WAIT state and the socket's resources are immediately recovered. The consequence is that there may be data loss if the client requests a resend of a TCP packet.
Just for the hell of it and for some experience for my MySQL Pro exam, I have got a base install of Debian 3.0 going on an old 540Mb disc I had lying around. I installed the Debian MySQL 3.23 server package and then tried to upgrade this using a 4.1 binary tarball release.
Debian 3.0 is using glibc2.2.5 but I thought it would work out fine using the glibc2.3 tarball of the latest 4.1 release. In the text above: "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."
However, I couldn't get the server to start due to errors over GLIC2.3 not being installed!
Luckily MySQL thoughtfully provides the answer in the 'Misc/Special Files' section of the 4.1 downloads list. There you will find a tarball that is compatible with glibc2.2.5 and it worked out fine.
My understanding of the glib23 statically linked release is that it's all self-contained and that I need no other software to install and run the thing. Please someone smart set me straight here.
A small snag I hit during the install is when running the grant table fixer script. This appears to be hardcoded to use /tmp/mysql.sock. I didn't want to mess aorund with hacking the script, so I simply specifyed a host param of 127.0.0.1. This means it will use TCP/IP thereby getting around the problem.
Hope this helps someone! Back to studying...
:-)
Add your own comment.