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.