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:
tar.gz
distribution) and install this instead.
mysql_install_db --force
; this will not execute the
resolveip
test in mysql_install_db
. The downside is that
you can't use host names in the grant tables; you must use IP numbers
instead (except for localhost
). If you are using an old MySQL
release that doesn't support --force
, you have to remove the
resolveip
test in mysql_install
with an editor.
mysqld
with su
instead of using --user
.
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.
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.