Go to the first, previous, next, last section, table of contents.

4 Installing MySQL

4.1 How to get MySQL

Check the MySQL home page for information about the current version and for downloading instructions.

However, the Internet connection at TcX is not so fast; we would prefer that you do the actual downloading from one of the mirror sites listed below.

Please report bad or out of date mirrors to webmaster@tcx.se.

Europe:

North America:

South America:

Asia:

Australia:

Africa:

4.2 Operating systems supported by MySQL

We use GNU Autoconf so it is possible to port MySQL to all modern systems with working Posix threads and a C++ compiler. The client code requires C++ but not threads. We use and develop the software ourselves primarily on Sun Solaris (versions 2.5 & 2.6) and to a lesser extent on RedHat Linux 5.0.

MySQL has been reported to compile sucessfully on the following operating system/thread package combinations. Note that for many operating systems, the native thread support works only in the latest versions.

4.3 Which MySQL version to use

The first decision to make is whether you want to use the latest development release or the last stable release.

Normally if you are beginning to use MySQL for the first time or trying to port it to some system for which there is no binary distribution, we recommend going with the development release. This is because there are usually no really bad bugs in the development release, and you can easily test it on your machine with the crash-me and benchmark tests. See section 11 The MySQL benchmark suite.

Otherwise, if you are running an old system and want to upgrade, but don't want to take chances with 3.22, you should upgrade to 3.21.33. We have tried to fix only fatal bugs and make small, relatively safe changes in this version.

The second decision to make is whether you want to use a source distribution or a binary distribution:

In the MySQL naming scheme, release numbers consist of three numbers and a suffix. For example, a release name like mysql-3.21.17-beta is interpreted like this:

All versions of MySQL are run through our standard tests and benchmarks to ensure that they are relatively safe to use. Since the standard tests are extended over time to check for all previously found bugs, the test suite keeps getting better.

Note that all releases have been tested at least with:

An internal test suite
This is part of a production system for a customer. It has many tables with hundreds of megabytes of data.
The MySQL benchmark suite
This runs a range of common queries. It is also a test to see whether the latest batch of optimizations actually made the code faster. See section 11 The MySQL benchmark suite.
The crash-me test
This tries to determine what features the database supports and what its capabilities and limitations are. See section 11 The MySQL benchmark suite.

Another test is that we use the newest MySQL version in our internal production environment, on at least one machine. We have more than 100 gigabytes of data to work with.

4.4 How and when updates are released

Well, MySQL is evolving quite rapidly here at TcX and we want to share this with other MySQL users. We try to make a release when we have a very useful feature that others seem to have a need for.

We also try to help out users who request features that are easy to implement. We also take note on what our licensed users want to have and we especially take notes of what our extended email supported customers want and try to help them out.

No one has to download a new release. The News section will tell you if the new release has something you really want. See section D MySQL change history.

We use the following policy when updating MySQL:

The 3.21.x version incorporates major portability changes for many different systems. When the 3.21 release is stable, we will remove the alpha/beta suffix and move active development to 3.22. Bugs will still be fixed in the stable version. We don't believe in a complete freeze, as this also leaves out bug fixes and things that "must be done". "Somewhat frozen" means that we may add small things that "almost surely will not affect anything that's already working".

4.5 Installation layouts

This section describes the default layout of the directories created by installing binary and source distributions.

A binary distribution is installed by unpacking it at the installation location you choose and creates the following directories in the location you choose (typically `/usr/local/mysql'):

Directory Contents of directory
`bin' Client programs, the mysqld server
`data' Log files, databases
`scripts' mysql_install_db
`share' Error message files
`sql-bench' Benchmarks

A source distribution is installed after you configure and compile it. By default, the installation step installs files under `/usr/local', in the following subdirectories:

Directory Contents of directory
`bin' Client programs and scripts
`libexec' The mysqld server
`share' Error message files
`sql-bench' Benchmarks
`var' Log files, databases

The layout of a source installation differs from that of a binary installation in the following ways:

4.6 Installing a MySQL binary distribution

The basic commands you have to do to use a MySQL binary distribution are: 

shell> scripts/mysql_install_db
shell> bin/safe_mysqld &

Here follows a more detailed description:

You need the following tools to install a MySQL binary distribution:

If you run into problems, PLEASE ALWAYS USE mysqlbug when posting questions to mysql@tcx.se. Even if the problem isn't a bug, mysqlbug gathers system information that will help others solve your problem. By not using mysqlbug, you lessen the likelihood of getting a solution to your problem! You will find mysqlbug in the `bin' directory after you unpack the distribution. See section 2.3 How to report bugs or problems.

To install a binary distribution, follow the steps below, then proceed to section 4.15 Post-installation setup and testing, for post-installation setup and testing.

  1. Pick the directory under which you want to unpack the distribution, and move into it. In the example below, we unpack the distribution under `/usr/local' and create a directory `/usr/local/mysql' into which MySQL is installed. (The following instructions therefore assume you have permission to create files in `/usr/local'. If that directory is protected, you will need to perform the installation as root.)
  2. Obtain a distribution file from one of the sites listed in section 4.1 How to get MySQL. MySQL binary distributions are provided as compressed tar archives and have names like `mysql-VERSION-OS.tar.gz', where VERSION is a number (e.g., 3.21.15), and OS indicates the type of operating system for which the distribution is intended (e.g., pc-linux-gnu-i586).
  3. Unpack the distribution and create the installation directory: 
    shell> gunzip < mysql-VERSION-OS.tar.gz | tar xvf -
shell> ln -s mysql-VERSION-OS mysql
    The first command creates a directory named `mysql-VERSION-OS'. The second command makes a symbolic link to that directory. This lets you refer more easily to the installation directory as `/usr/local/mysql'.
  4. Change into the installation directory: 
    shell> cd mysql
    You will find several files and subdirectories in the mysql directory. The most important for installation purposes are the `bin' and `scripts' subdirectories.
    `bin'
    This directory contains client programs and the server You should add the full pathname of this directory to your PATH environment variable so that your shell finds the MySQL programs properly.
    `scripts'
    This directory contains the mysql_install_db script used to initialize the server access permissions
  5. If you would like to use mysqlaccess and have the MySQL distribution in some nonstandard place, you must change the location where mysqlaccess expects to find the mysql client. Edit the `bin/mysqlaccess' script at approximately line 18. Search for a line that looks like this: 
    $MYSQL     = '/usr/local/bin/mysql';    # path to mysql executable
    Change the path to reflect the location where mysql actually is stored on your system. If you do not do this, you will get a broken pipe error when you run mysqlaccess.
  6. If you want to install support for the Perl DBI/DBD interface, see section 4.10 Perl installation comments.
  7. If you would like MySQL to start automatically when you boot your machine, you can copy support-files/mysql.server to where your system has its startup files. More information can be found in the support-files/mysql.server script itself. section 4.15.3 Automatically starting and stopping MySQL.

After everything has been unpacked and installed, you should initialize and test your distribution. See section 4.15 Post-installation setup and testing.

4.6.1 Building client programs

If you compile MySQL clients that you've written yourself or that you obtain from a third party, they must be linked using the -lmysqlclient option on the link command. You may also need to specify a -L option to tell the linker where to find the library. For example, if the library is installed in `/usr/local/mysql/lib', use -L/usr/local/mysql/lib -lmysqlclient on the link command.

For clients that use MySQL header files, you may need to specify a -I option (for example, -I/usr/local/mysql/include) when you compile them, so the compiler can find the header files.

4.6.2 System-specific notes

The following sections indicate some of the issues that have been observed to occur on particular systems.

4.6.2.1 Linux notes

4.6.2.2 HP-UX notes

The binary distribution of MySQL for HP-UX is distributed as an HP depot file. This means that you must be running at least HP-UX 10.x to have access to HP's software depot tools.

The HP version of MySQL was compiled on an HP 9000/8xx server under HP-UX 10.20, and uses MIT-pthreads. It is known to work well under this configuration. This version does not use HP's native thread package. It is highly unlikely that MySQL will use HP native threads on anything but HP-UX 10.30 or later.

Other configurations that may work:

The following configurations almost definitely won't work:

To install the distribution, use one of the commands below, where /path/to/depot is the full path to the depot file:

The depot places binaries and libraries in `/opt/mysql' and data in `/var/opt/mysql'. The depot also creates the appropriate entries in `/sbin/init.d' and `/sbin/rc2.d' to start the server automatically at boot time. Obviously, this entails being root to install.

4.7 Installing a MySQL source distribution

You need the following tools to build and install MySQL from source:

If you run into problems, PLEASE ALWAYS USE mysqlbug when posting questions to mysql@tcx.se. Even if the problem isn't a bug, mysqlbug gathers system information that will help others solve your problem. By not using mysqlbug, you lessen the likelihood of getting a solution to your problem! You will find mysqlbug in the `scripts' directory after you unpack the distribution. See section 2.3 How to report bugs or problems.

4.7.1 Quick installation overview

The basic commands you have to do to install MySQL from source are: 

shell> configure --prefix=/usr/local/mysql
shell> make
shell> make install
shell> scripts/mysql_install_db
shell> /usr/local/mysql/bin/safe_mysqld &

Here follows a more detailed description:

To install a source distribution, follow the steps below, then proceed to section 4.15 Post-installation setup and testing, for post-installation initialization and testing.

  1. Pick the directory under which you want to unpack the distribution, and move into it.
  2. Obtain a distribution file from one of the sites listed in section 4.1 How to get MySQL. MySQL source distributions are provided as compressed tar archives and have names like `mysql-VERSION.tar.gz', where VERSION is a number like 3.22.15-gamma.
  3. Unpack the distribution into the current directory: 
    shell> gunzip < mysql-VERSION.tar.gz | tar xvf -
    This command creates a directory named `mysql-VERSION'.
  4. Change into the top-level directory of the unpacked distribution: 
    shell> cd mysql-VERSION
  5. Configure the release and compile everything: 
    shell> ./configure --prefix=/usr/local/mysql
shell> make
    When you run configure, you might want to specify some options. Run ./configure --help for a list of options. section 4.7.3 Typical configure options, discusses some of the more useful options. If configure fails, and you are going to send mail to `config.log' that you think can help solve the problem. Also include the last couple of lines of output from configure if configure aborts. Post the bug report using the mysqlbug script. See section 2.3 How to report bugs or problems. If the compile fails, see section 4.8 Problems compiling?, for help with a number of common problems.
  6. Install everything: 
    shell> make install
    You might need to run this command as root.
  7. Create the MySQL grant tables 
    shell> scripts/mysql_install_db
  8. If you want to install support for the Perl DBI/DBD interface, see section 4.10 Perl installation comments.
  9. If you would like MySQL to start automatically when you boot your machine, you can copy support-files/mysql.server to where your system has its startup files. More information can be found in the support-files/mysql.server script itself, and in section 4.15.3 Automatically starting and stopping MySQL.

After everything has been installed, you should initialize and test your distribution.

You can start the MySQL server with: 

shell> cd mysql-install-directory
shell> bin/safe_mysqld &

Note that MySQL versions before 3.22.10 started the MySQL server when you run mysql_install_db. This is no longer true!

See section 4.15 Post-installation setup and testing.

4.7.2 Applying patches

Sometimes patches appear on the mailing list. To apply a patch, change into the top-level directory of your MySQL source tree and run these commands: 

shell> gunzip < patch-file-name.gz | patch -p1
shell> rm config.cache
shell> make clean

Then follow the instructions for a normal source install, beginning with the ./configure step. After running the make install step, restart your MySQL server.

You may need to bring down any currently running server before you run make install. Some systems do not allow you to install a new version of a program if it replaces the version that is currently executing.

4.7.3 Typical configure options

The configure script gives you a great deal of control over how you configure your MySQL distribution. Typically you do this using options on the configure command line. You can also affect configure using certain environment variables. For a list of options supported by configure, run this command: 

shell> ./configure --help

Some of the more commonly-used configure options are described below:

4.8 Problems compiling?

All MySQL programs compile cleanly for us with no warnings on Solaris using gcc. On other systems, warnings may occur due to differences in system include files. See section 4.9 MIT-pthreads notes, for warnings that may occur when using MIT-pthreads. For other problems, check the list below.

The solution to many problems involves reconfiguring. If you do need to reconfigure, take note of the following:

To prevent old configuration information or object files from being used, run these commands before rerunning configure: 

shell> rm config.cache
shell> make clean

Alternatively, you can run make distclean.

The list below describes some of the problems compiling MySQL that have been found to occur most often:

4.9 MIT-pthreads notes

This section describes some of the issues involved in using MIT-pthreads.

If your system does not provide native thread support, you will need to build MySQL using the MIT-pthreads package. This includes most FreeBSD systems, SunOS 4.x, Solaris 2.4 and earlier, and some others. See section 4.2 Operating systems supported by MySQL.

4.10 Perl installation comments

MySQL support for the Perl DBI/DBD interface is distributed separately from the main MySQL distribution, as of release 3.22.8. If you want to install Perl support, check http://www.mysql.com/Contrib for the files you will need.

The Perl client code for the DBD/DBI interface requires Perl 5.004 or later. The interface will not work if you have an older version of Perl.

The Perl distributions are provided as compressed tar archives and have names like `MODULE-VERSION.tar.gz', where MODULE is the module name and VERSION is the version number. You should get the Data-Dumper, DBI, and Msql-Mysql-modules archives. Once you have them, install them using the procedure shown below. The example shown below is for the Data-Dumper module, but the procedure is the same for all three modules.

  1. Unpack the distribution into the current directory: 
    shell> gunzip < Data-Dumper-VERSION.tar.gz | tar xvf -
    This command creates a directory named `Data-Dumper-VERSION'.
  2. Change into the top-level directory of the unpacked distribution: 
    shell> cd Data-Dumper-VERSION
  3. Build the distribution and compile everything: 
    shell> perl Makefile.PL
shell> make
shell> make test
shell> make install

After you've installed the three modules, run make test in the Msql-Mysql-modules directory to exercise the interface code. (The server must be running for this to work.)

If you don't have the right to install Perl modules in the system directory or if you to install local Perl modules, the following reference may help you: 

http://www.iserver.com/support/contrib/perl5/modules.html

Look under the heading Installing New Modules that Require Locally Installed Modules.

4.10.1 Problems using the Perl DBI/DBD interface

If perl reports that it can't find the ../mysql/mysql.so module, then the problem is probably that perl can't locate the shared library `libmysqlclient.so'.

You can fix this by any of the following methods:

If you get the following errors from DBD-mysql, you are probably using gcc (or using an old binary compiled with gcc): 

/usr/bin/perl: can't resolve symbol '__moddi3'
/usr/bin/perl: can't resolve symbol '__divdi3'

Add -L/usr/lib/gcc-lib/... -lgcc to the link command when the `mysql.so' library gets built (check the output from make for `mysql.so' when you compile the Perl client). The -L option should specify the path to the directory where `libgcc.a' is located on your system.

Another cause of this problem may be that Perl and MySQL aren't both compiled with gcc. In this case, you can solve the mismatch by compiling both with gcc.

If you want to use the Perl module on a system that doesn't support dynamic linking (like SCO) you can generate a static version of Perl that includes DBI and DBD-mysql. The way this works is that you generate a version of Perl with the DBI code linked in and install it on top of your current Perl. Then you use that to build a version of Perl that additionally has the DBD code linked in, and install that.

On SCO, you must have the following environment variables set: 

shell> LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/progressive/lib
or
shell> LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:/usr/progressive/lib:/usr/skunk/lib
shell> LIBPATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:/usr/progressive/lib:/usr/skunk/lib
shell> MANPATH=scohelp:/usr/man:/usr/local1/man:/usr/local/man:/usr/skunk/man:

First, you create a Perl that includes a statically-linked DBI by running these commands in the `perl/DBI' directory: 

shell> perl Makefile.PL LINKTYPE=static
shell> make
shell> make install
shell> make perl

After this you must install the new Perl. The output of make perl will indicate the exact make command you will need to execute to perform the installation. On SCO, this is make -f Makefile.aperl inst_perl MAP_TARGET=perl.

Next you create Perl that includes a statically-linked DBD::mysql by running these commands in the `perl/Mysql-modules' directory: 

shell> perl Makefile.PL LINKTYPE=static
shell> make
shell> make install
shell> make perl

You should also install this new Perl. Again, the output of make perl indicates the command to use.

4.11 System-specific notes

The following sections indicate some of the issues that have been observed to occur on particular systems.

4.11.1 Solaris notes

On Solaris, you may run into trouble even before you get the MySQL distribution unpacked! Solaris tar can't handle long file names, so you may see an error like this when you unpack MySQL: 

x mysql-3.22.12-beta/bench/Results/ATIS-mysql_odbc-NT_4.0-cmp-db2,informix,ms-sql,mysql,oracle,solid,sybase, 0 bytes, 0 tape blocks
tar: directory checksum error

In this case, you must use GNU tar (gtar) to unpack the distribution. You can find a precompiled copy for Solaris at http://www.mysql.com/Downloads/.

Sun native threads work only on Solaris 2.5 and higher. For 2.4 and earlier versions, MySQL will automaticly use MIT-pthreads. See section 4.9 MIT-pthreads notes.

If you have the Sun Workshop 4.2 compiler, you can run configure like this: 

shell> CC=cc CFLAGS="-Xa -fast -xstrconst -mt" \
       CXX=CC CXXFLAGS="-xsb -noex -fast -mt" \
       ./configure

You may also have to edit the configure script to change this line: 

#if !defined(__STDC__) || __STDC__ != 1

to this: 

#if !defined(__STDC__)

If you turn on __STDC__ with the -Xc option, the Sun compiler can't compile with the Solaris `pthread.h' header file. This is a Sun bug (broken compiler or broken include file).

If mysqld issues the error message shown below when you run it, you have tried to compile MySQL with the Sun compiler without enabling the multi-thread option -mt: 

libc internal error: _rmutex_unlock: rmutex not held

Add -mt to CFLAGS and CXXFLAGS and try again.

If you get the following error when compiling MySQL with gcc, it means that your gcc is not configured for your version of Solaris! 

shell> gcc -O3 -g -O2 -DDBUG_OFF  -o thr_alarm ...
./thr_alarm.c: In function `signal_hand':
./thr_alarm.c:556: too many arguments to function `sigwait'

The proper thing to do in this case is to get the newest version of egcs or gcc and compile it with your current gcc compiler! At least for Solaris 2.5, almost all binary versions of gcc have old, unusable include files that will break all programs that use threads (and possibly other programs)!

Note that gcc 2.8.1 has a couple on bugs on Sparc platforms! On Sparc, we recommend you use egcs 1.0.3a. If you are using egcs 1.1 or egcs 1.1.1 you MUST compile MySQL with -O1 as higher optimization levels produces wrong code.

The recommended configure line when using egcs 1.1 or egcs 1.1.1 is: 

shell> CC=gcc CFLAGS="-O1" \
       CXX=gcc CXXFLAGS="-O1 -felide-constructors -fno-exceptions -fno-rtti" \
       ./configure --prefix=/usr/local/mysql --with-low-memory

As Solaris doesn't provide static versions of all system libraries (libpthreads and libdl), you can't compile MySQL with --static. If you try to do this, you will get the error: 

ld: fatal: library -ldl: not found

Solaris 2.7 has some bugs in the include files. If you get the following error when you use gcc: 

/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of the previous
definition

You can do the following to avoid this:

copy /usr/include/widec.h to .../lib/gcc-lib/os/gcc-version/include and change row 41 from: 

#if     !defined(lint) && !defined(__lint)

to

#if     !defined(lint) && !defined(__lint) && !defined(getwc)

You can of course edit `/usr/include/widec.h' directly. After this you should remove `config.cache' and run configure again!

If too many processes try to connect very rapidly to mysqld, you will see this error in the MySQL log: 

Error in accept: Protocol error

You might try starting the server with the --set-variable back_log=50 option as a workaround for this.

If you are linking your own MySQL client and get the error: 

ld.so.1: ./my: fatal: libmysqlclient.so.#: open failed: No such file or directory

when executing them, the problem can be avoided by one of the following methods:

•
Link the client with the following flag (instead of -Lpath): -Wl,r/path-libmysqlclient.so
•
Copy libmysqclient.so to `/usr/lib'
•
Set the LD_RUN_PATH environment to the path to `libmysqlclient.so' before running your client.

4.11.2 Solarix x86 notes

If you are using gcc or egcs on Solaris x86 and you experience problems with core dumps under load, you should use the following configure command: 

shell> CC=gcc CFLAGS="-O6 -fomit-frame-pointer" \
       CXX=gcc \
       CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" \
       ./configure --prefix=/usr/local/mysql

This will avoid problems with the libstdc++ library and with C++ exceptions.

If this doesn't help, you should compile a debug version and run this with a trace file or under gdb. See section 19.10 Debugging MySQL.

4.11.3 SunOS 4 notes

On SunOS 4, MIT-pthreads is needed. This in turn means you will need GNU make to compile MySQL.

Some SunOS 4 systems have problems with dynamic libraries and libtool. You can use the following configure line to avoid this problem. 

./configure --disable-shared --with-mysqld-ldflags=-all-static

When compiling readline, you may get warnings about duplicate defines. These may be ignored.

When compiling mysqld, there will be some implicit declaration of function warnings. These may be ignored.

4.11.4 Linux notes (all Linux versions)

If you can't start mysqld or if mysql_install_db doesn't work, please continue reading! This only happens on Linux system with problems in the LinuxThreads or libc/glibc libraries. There are a lot of simple workarounds to get MySQL to work! The simplest is to use the binary version of MySQL (not the RPM) for Linux x86; One nice aspect of this version is that it's probably 10% faster than any version you would compile yourself! See section 10.3 How compiling and linking affects the speed of MySQL.

isamchk hangs with libc.so.5.3.12. Upgrading to the newest libc fixes this problem.

When using LinuxThreads you will see a minimum of three processes running. These are in fact threads. There will be one thread for the LinuxThreads manager, one thread to handle connections, and one thread to handle alarms and signals.

If you are using LinuxThreads and mysqladmin shutdown doesn't work, you have to upgrade to LinuxThreads 0.7.1 or newer.

If you are using RedHat, you might get errors like this: 

/usr/bin/perl is needed...
/usr/sh is needed...
/usr/sh is needed...

If so, you should upgrade your version of rpm to `rpm-2.4.11-1.i386.rpm' and `rpm-devel-2.4.11-1.i386.rpm' (or later).

You can get the upgrades of libraries to RedHat 4.2 from ftp://ftp.redhat.com/updates/4.2/i386. Or http://www.sunsite.unc.edu/pub/Linux/distributions/redhat/code/rpm/ for other distributions.

If you are linking an own MySQL client and get the error: 

ld.so.1: ./my: fatal: libmysqlclient.so.4: open failed: No such file or directory

when executing them, the problem can be avoided by one of the following methods:

•
Link the client with the following flag (instead of -Lpath): -Wl,r/path-libmysqlclient.so
•
Copy libmysqclient.so to `/usr/lib'
•
Set the LD_RUN_PATH environment to the path to `libmysqlclient.so' before running your client.

4.11.4.1 Linux-x86 notes

LinuxThreads should be installed before configuring MySQL!

MySQL requires libc version 5.4.12 or newer. It's known to work with libc 5.4.46. glibc version 2.0.6 and later should also work. There have been some problems with the glibc RPMs from RedHat so if you have problems, check whether or not there are any updates! The glibc 2.0.7-19 RPM is known to work.

On some older Linux distributions, configure may produce an error like this: 

Syntax error in sched.h. Change _P to __P in the /usr/include/sched.h file.
See the Installation chapter in the Reference Manual.

Just do what the error message says and add an extra underscore to the _P macro that has only one underscore, then try again.

You may get some warnings when compiling; those shown below can be ignored: 

mysqld.cc -o objs-thread/mysqld.o
mysqld.cc: In function `void init_signals()':
mysqld.cc:315: warning: assignment of negative value `-1' to `long unsigned int'
mysqld.cc: In function `void * signal_hand(void *)':
mysqld.cc:346: warning: assignment of negative value `-1' to `long unsigned int'

In Debian GNU/Linux, if you want MySQL to start automatically when the system boots, do the following: 

shell> cp support-files/mysql.server /etc/init.d/mysql.server
shell> /usr/sbin/update-rc.d mysql.server defaults 99

mysql.server can be found in the `share/mysql' directory under the MySQL installation directory, or in the `support-files' directory of the MySQL source tree.

If mysqld always core dumps when it starts up, the problem may be that you have an old `/lib/libc.a'. Try renaming it, then remove `sql/mysqld' and do a new make install and try again. This problem has been reported on some Slackware installations. RedHat 5.0 has also a similar problem with some new glibc versions. See section 4.11.4.2 RedHat 5.0 notes.

If you get the following error when linking mysqld, it means that your `libg++.a' is not installed correctly: 

/usr/lib/libc.a(putc.o): In function `_IO_putc':
putc.o(.text+0x0): multiple definition of `_IO_putc'

You can avoid using `libg++.a' by running configure like this: 

shell> CXX=gcc ./configure

4.11.4.2 RedHat 5.0 notes

If you have any problems with MySQL on RedHat, you should start by upgrading glibc to the newest possible version!

If you install all the official RedHat patches (including glibc-2.0.7-19 and glibc-devel-2.0.7-19), both the binary and source distributions of MySQL should work without any trouble!

The updates are needed since there is a bug in glibc 2.0.5 in how pthread_key_create variables are freed. With glibc 2.0.5, you must use a statically-linked MySQL binary distribution. If you want to compile from source, you must install the corrected version of LinuxThreads from http://www.mysql.com/Downloads/Linux or upgrade your glibc.

If you have an incorrect version of glibc or LinuxThreads, the symptom is that mysqld crashes after each connection. For example, mysqladmin version will crash mysqld when it finishes!

Another symptom of incorrect libraries is that mysqld crashes at once when it starts. On some Linux systems, this can be fixed by configuring like this: 

shell> ./configure --with-mysqld-ldflags=-all-static

On Redhat 5.0, the easy way out is to install the glibc 2.0.7-19 RPM and run configure without the --with-mysqld-ldflags=-all-static option.

For the source distribution of glibc 2.0.7, a patch that is easy to apply and is tested with MySQL may be found at http://www.mysql.com/Download/Linux/glibc-2.0.7-total-patch.tar.gz.

If you experience crashes like these when you build MySQL, you can always download the newest binary version of MySQL. This is statically-linked to avoid library conflicts and should work on all Linux systems!

MySQL comes with an internal debugger that can generate trace files with a lot of information that can be used to find and solve a wide range of different problems. See section 19.10 Debugging MySQL.

4.11.4.3 RedHat 5.1 notes

The glibc of RedHat 5.1 (glibc 2.0.7-13) has a memory leak, so to get a stable MySQL version, you must upgrade glibc to 2.0.7-19, downgrade glibc or use a binary version of mysqld. If you don't do this, you will encounter memory problems (out of memory, etc., etc.). The most common error in this case is: 

Can't create a new thread (errno 11). If you are not out of available
memory, you can consult the manual for any possible OS dependent bug

After you have upgraded to glibc 2.0.7-19, you can configure MySQL with dynamic linking (the default), but you cannot run configure with the --with-mysqld-ldflags=-all-static option until you have installed glibc 2.0.7-19 from source!

You can check which version of glibc you have with rpm -q glibc.

4.11.4.4 Linux-Sparc notes

In some implementations, readdir_r() is broken. The symptom is that SHOW DATABASES always returns an empty set. This can be fixed by removing HAVE_READDIR_R from `config.h' after configuring and before compiling.

Some problems will require patching your Linux installation. The patch can be found at http://www.mysql.com/patches/Linux-sparc-2.0.30.diff. This patch is against the Linux distribution `sparclinux-2.0.30.tar.gz' that is available at vger.rutgers.edu (a version of Linux that was never merged with the official 2.0.30). You must also install LinuxThreads 0.6 or newer.

Thanks to jacques@solucorp.qc.ca for this information.

4.11.4.5 Linux-Alpha notes

The first problem is LinuxThreads. The RedHat distribution uses an old (broken) LinuxThreads version, so you must patch LinuxThreads for Alpha. Use the following procedure:

  1. Obtain the glibc2.5c source from any GNU FTP site.
  2. Get the file ftp://www.mysql.com/pub/mysql/linux/patched-glibc-linuxthreads-0.6.tar.gz. This includes a fixed .c file. Copy this to the glibc `./linuxthreads' directory.
  3. Configure and compile glibc (You have to read the manual how to do this together with LinuxThreads), but don't install it!
  4. In the `/usr/lib' directory, rename your old version of `libpthread.a' to `libpthread.a-old'.
  5. Copy the file `glibc.../linuxthreads/libpthread.a' to `/usr/lib'.
  6. Configure MySQL with the following command: 
    shell> CC=gcc CCFLAGS="-Dalpha_linux_port" \
       CXX=gcc CXXFLAGS="-O3 -Dalpha_linux_port" \
       ./configure --prefix=/usr/local/mysql
  7. Try to compile mysys/thr_lock and mysys/thr_alarm. Test that these programs work! (Invoke each one with no arguments. Each should end with test_succeeded if everything was okay.)
  8. Recompile mysqld.

Note that Linux-Alpha is still an alpha-quality platform for MySQL. With RedHat 5.0 and the patched LinuxThreads, you have a very good chance of it working.

If you have problems with signals (MySQL dies unexpectedly under high load) you may have found an OS bug with threads and signals. In this case you can tell MySQL not to use signals by configuring with: 

shell> CFLAGS=-DDONT_USE_THR_ALARM CXXFLAGS=-DDONT_USE_THR_ALARM ./configure ...

This doesn't affect the performance of MySQL, but has the side effect that you can't kill clients that are "sleeping" on a connection with mysqladmin kill or mysqladmin shutdown. The client will instead die when it issues its next command.

4.11.4.6 MkLinux notes

MySQL should work on MkLinux with the newest glibc package (tested with glibc 2.0.7).

4.11.5 Linux RPM notes

The recommended way to install MySQL on linux is by a RPM. The MySQL RPMS is currently being build on a RedHat 5.1 system but should work on other versions of Linux that supports RPM as well.

The RPM places data in `/var/lib/mysql'. The RPM also creates the appropriate entries in `/sbin/rc.d/' to start the server automatically at boot time.

4.11.6 Alpha-DEC-Unix notes

When compiling threaded programs under Digital UNIX, the documentation recommends the -pthread option for cc and cxx and the libraries -lmach -lexc (in addition to -lpthread). You should run configure something like this: 

shell> CC="cc -pthread" CXX="cxx -pthread -O" \
       ./configure -with-named-thread-libs="-lpthread -lmach -lexc -lc"

When compiling mysqld, you may see a couple of warnings like this: 

mysqld.cc: In function void handle_connections()':
mysqld.cc:626: passing long unsigned int *' as argument 3 of
accept(int,sockadddr *, int *)'

You can safely ignore these warnings. They occur because configure can't detect warnings, only errors.

If you start the server directly from the command line, you may have problems with it dying when you log out. (When you log out, your outstanding processes receive a SIGHUP signal.) If so, try starting the server like this: 

shell> nohup mysqld [options] &

nohup causes the command following it to ignore any SIGHUP signal sent from the terminal. Alternatively, start the server by running safe_mysqld, which invokes mysqld using nohup for you.

4.11.7 Alpha-DEC-OSF1 notes

If you have problems compiling and have DEC CC and gcc installed, try running configure like this: 

shell> CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 \
       ./configure --prefix=/usr/local/mysql

If you get problems with the `c_asm.h' file, you can create and use a 'dummy' `c_asm.h' file with: 

shell> touch include/c_asm.h
shell> CC=gcc CFLAGS=-I./include CXX=gcc CXXFLAGS="-O3 ./configure --prefix=/usr/local/mysql

On OSF1 V4.0D and compiler "DEC C V5.6-071 on Digital UNIX V4.0 (Rev. 878)" the compiler had some strange behavior (undefined asm symbols). /bin/ld also appears to be broken (problems with _exit undefined when linking mysqld). On this system, we have managed to compile MySQL with the following configure line, after replacing /bin/ld with the version from OSF 4.0C: 

shell> CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql

In some versions of OSF1, the alloca() function is broken. Fix this by removing the line in `config.h' that defines 'HAVE_ALLOCA'.

The alloca() function also may have an incorrect prototype in /usr/include/alloca.h. This warning resulting from this can be ignored.

configure will use the following thread libraries automatically: -with-named-thread-libs="-lpthread -lmach -lexc -lc".

When using gcc, you can also try running configure like this: 

shell> CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ....

If you have problems with signals (MySQL dies unexpectedly under high load) you may have found an OS bug with threads and signals. In this case you can tell MySQL not to use signals by configuring with: 

shell> CFLAGS=-DDONT_USE_THR_ALARM CXXFLAGS=-DDONT_USE_THR_ALARM ./configure ...

This doesn't affect the performance of MySQL, but has the side effect that you can't kill clients that are "sleeping" on a connection with mysqladmin kill or mysqladmin shutdown. The client will instead die when it issues its next command.

4.11.8 SGI-IRIX notes

You may have to undefine some things in `config.h' after running configure and before compiling.

In some Irix implementations, the alloca() function is broken. If the mysqld server dies on some SELECT statements, remove the lines from `config.h' that define HAVE_ALLOC and HAVE_ALLOCA_H. If mysqladmin create doesn't work, remove the line from `config.h' that defines HAVE_READDIR_R. You may have to remove the HAVE_TERM_H line as well.

Irix 6.2 doesn't support POSIX threads out of of the box. You must install these patches, which are available from SGI if you have support: 1403, 1404, 1644, 1717, 1918, 2000, 2044.

If you get the something like the following error when compiling `mysql.cc': 

"/usr/include/curses.h", line 82: error(1084): invalid combination of type

Then type the following in the top-level directory of your MySQL source tree: 

shell> extra/replace bool curses_bool < /usr/include/curses.h > include/curses.h
shell> make

There have also been reports of scheduling problems. If only one thread is running, things go slow. Avoid this by starting another client. This may lead to a 2-to-10-fold increase in execution speed thereafter for the other thread.

This is a poorly-understood problem with IRIS threads; you may have to improvise to find solutions until this can be fixed.

If you are compiling with gcc, you can use the following configure command: 

shell> CC=gcc CXX=gcc CXXFLAGS=-O3 \
       ./configure --prefix=/usr/local/mysql --with-thread-safe-client

4.11.9 FreeBSD notes

If you notice that configure will use MIT-pthreads, you should read the MIT-pthreads notes. See section 4.9 MIT-pthreads notes.

If you get an error on make install that it can't find `/usr/include/pthreads', configure didn't detect that you need MIT-pthreads on FreeBSD. This is fixed by doing: 

shell> rm config.cache
shell> ./configure --with-mit-threads

The FreeBSD make behavior is slightly different from that of GNU make. If you have make-related problems, you should install GNU make.

If mysql or mysqladmin takes a long time to respond, a user said the following:

Are you running the ppp user process? On one FreeBSD box (2.2.5) MySQL clients takes a couple of seconds to connect to mysqld if the ppp process is running.

FreeBSD is also known to have a very low default file handle limit. See section 16.9 File not found.

If you have a problem with SELECT NOW() returning values in GMT and not your local time, you have to set the TZ environment variable to your current timezone. This should be done for the environment in which the server runs, for example, in safe_mysqld or mysql.server.

Make sure that you modify the `/etc/hosts' file so that the localhost entry is correct (otherwise you will have problems connecting to the database. The `/etc/hosts' file should start with a line: 

127.0.0.1       localhost localhost.your.domain

If you are using FreeBSD 2.2.6, don't forget to apply the ttcp and mmap-22 patches to the OS (for security reasons). Please see http://www.freebsd.org for these CERT patches.

If you are using FreeBSD 2.2.7 and you have problems killing the mysqld daemon, you should cvsup new sources and recompile libc_r.

4.11.9.1 FreeBSD-3.0 notes

You have to run configure with the --with-named-thread-libs=-lc_r option.

The pthreads library for FreeBSD doesn't contain the sigwait() function and there are some bugs in it. To fix this, get the `FreeBSD-3.0-libc_r-1.0.diff' file and apply this in the `/usr/src/lib/libc_r/uthread' directory. Then follow the instructions that can be found with man pthread about how to recompile the libc_r library.

You can test if you have a "modern" libpthread.a with this command: 

shell> nm /usr/lib/libc_r.a | grep sigwait

If the above doesn't find sigwait, you must use the patch above and recompile libc_r.

4.11.10 BSD/OS 2.# notes

If you get the following error when compiling MySQL, your ulimit for virtual memory is too low: 

item_func.h: In method `Item_func_ge::Item_func_ge(const Item_func_ge &)':
item_func.h:28: virtual memory exhausted
make[2]: *** [item_func.o] Error 1

Try using ulimit -v 80000 and run make again. If this doesn't work and you are using bash, try switching to csh or sh; Some BSDI users have reported problems with bash and ulimit.

If you are using gcc, you may also use have to use the --with-low-memory flag to configure to be able to compile `sql_yacc.cc'.

If you have a problem with SELECT NOW() returning values in GMT and not your local time, you have to set the TZ environment variable to your current timezone. This should be done for the environment in which the server runs, for example in safe_mysqld or mysql.server.

4.11.10.1 BSD/OS 3.# notes

  1. Upgrade to BSD/OS 3.1. If that is not possible, install BSDIpatch M300-038.
  2. Use the following command when configuring MySQL: 
    shell> env CXX=shlicc++ CC=shlicc2 \
       ./configure \
           --prefix=/usr/local/mysql \
           --localstatedir=/var/mysql \
           --without-perl \
           --with-unix-socket-path=/var/mysql/mysql.sock
    The following is also known to work: 
    shell> env CC=gcc CXX=gcc CXXFLAGS=-O3 \
       ./configure \
           --prefix=/usr/local/mysql \
           --with-unix-socket-path=/var/mysql/mysql.sock
    You can change the directory locations if you wish, or just use the defaults by not specifying any locations.
  3. If you have problems with performance under heavy load, try using the --skip-thread-priority option to safe_mysqld! This will run all threads with the same priority; on BSDI 3.1, this gives better performance. (At least until BSDI fixes their thread scheduler).

If you get the error virtual memory exhausted while compiling, you should try using ulimit -v 80000 and run make again. If this doesn't work and you are using bash, try switching to csh or sh; Some BSDI users have reported problems with bash and ulimit.

4.11.11 SCO notes

The current port is tested only on a "sco3.2v5.0.4" system. There has also been a lot of progress on a port to "sco 3.2v4.2".

  1. For OpenServer 5.0.X You need to use GDS in Skunkware 95 (95q4c). This is necessary because GNU gcc 2.7.2 in Skunkware 97 does not have GNU as.
  2. You need the port of GCC 2.5.? for this product and the Development system. They are required on this version of SCO UNIX. You cannot just use the GCC Dev system.
  3. You should get FSU thread package and install this first. This can be found at http://www.cs.wustl.edu/~schmidt/ACE_wrappers/FSU-threads.tar.gz. You can also get a precompiled package from ftp://www.mysql.com/pub/mysql/Downloads/SCO/FSU-threads-3.5c.tar.gz.
  4. FSU pthreads can be compiled with SCO UNIX 4.2 with tcpip. Or OpenServer 3.0 or Open Desktop 3.0 (OS 3.0 ODT 3.0), with the SCO Development System installed using a good port of GCC 2.5.X ODT or OS 3.0 you will need a good port of GCC 2.5.? There are a lot of problems without a good port. The port for this product requires the SCO UNIX Development system. Without it, you are missing the libraries and the linker that is needed.
  5. To build FSU pthreads in your system, do the following:
    1. Run ./configure in the `threads/src' directory and select the SCO OpenServer option. This command copies `Makefile.SCO5' to `Makefile'.
    2. Run make.
    3. To install in the default `/usr/include' directory, login as root and cd to `thread/src' directory, and run make install.
  6. Remember to use GNU make when making MySQL.
  7. If you don't start safe_mysqld as root, you will probably only get the default 110 open files per process. mysqld will write a note about this in the log file.
  8. With SCO 3.2V4.2, you must use a FSU-pthreads version 3.5c or newer. The following configure command should work: 
    shell> CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4" \
       ./configure \
           --with-debug --prefix=/usr/local/mysql \
           --with-named-thread-libs="-lgthreads -lsocket -lgen -lgthreads" \
           --with-named-curses-libs="-lcurses" \
           --without-perl
    You may get some problems with some include files. In this case you can find new SCO-specific include files at ftp://www.mysql.com/pub/mysql/Downloads/SCO/SCO-3.2v4.2-includes.tar.gz. You should unpack this file in the `include' directory of your MySQL source tree.

SCO development notes:

4.11.12 SCO Unixware 7.0 notes

MySQL 3.22.13 fixes some portability problems under Unixware so you must use at least this version.

We have been able to compile MySQL with the following configure line on UnixWare 7.0.1: 

CC=cc CXX=CC ./configure --prefix=/usr/local/mysql

4.11.13 IBM-AIX notes

Automatic detection of xlC is missing from Autoconf, so something like this is needed when using the IBM compiler: 

shell> CC="xlc_r -ma -O3 -qstrict" CXX="xlC_r -ma -O3 -qstrict" \
       ./configure

If you are using egcs to compile MySQL, you MUST use the -fno-exceptions flag, as the exception handling in egcs is not thread-safe! (This is tested with egcs 1.1). We recommend the following configure line with egcs and gcc on AIX: 

shell> CXX=gcc CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti" \
       ./configure --prefix=/home/monty --with-debug --with-low-memory

If you have problems with signals (MySQL dies unexpectedly under high load) you may have found an OS bug with threads and signals. In this case you can tell MySQL not to use signals by configuring with: 

shell> CFLAGS=-DDONT_USE_THR_ALARM CXX=gcc \
       CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -DDONT_USE_THR_ALARM" \
       ./configure --prefix=/home/monty --with-debug --with-low-memory

This doesn't affect the performance of MySQL, but has the side effect that you can't kill clients that are "sleeping" on a connection with mysqladmin kill or mysqladmin shutdown. The client will instead die when it issues its next command.

4.11.14 HP-UX notes

There are a couple of "small" problems when compiling MySQL on HP-UX. We recommend that you use gcc instead of the HP-UX native compiler as gcc produces better code!

gcc 2.8.0 can't compile readline on HP-UX (an internal compiler error occurs) if you are compiling with -O6. On the other hand, MIT-pthreads can't be compiled with the HP-UX compiler, because it can't compile .S (assembler) files. We got MySQL to compile on HP-UX 10.20 by doing the following: 

shell> CC=gcc CXX=gcc ./configure --prefix=/usr/local/mysql --with-low-memory
shell> cd readline
shell> edit Makefile and change -O6 to something lower
shell> cd ..
shell> make
shell> make install
shell> scripts/mysql_install_db
shell> /usr/local/mysql/bin/safe_mysqld &

4.12 Win32 notes

The MySQL-Win32 version has by now proven itself to be very stable. The Win32 version of MySQL has the same features as the corresponding Unix version with the following exceptions:

Win95 and threads
Win95 leaks about 200 bytes of main memory for each thread creation. Because of this, you shouldn't run mysqld for an extended time on Win95 if you do many connections, since each connection in MySQL creates a new thread! NT and Win98 don't suffer from this bug.
Blocking read
MySQL uses a blocking read for each connection. This means that: We plan to fix this in the near future.
UDF functions
For the moment, MySQL-Win32 does not support user definable functions.
DROP DATABASE
You can't drop a database that is in use by some thread.
Killing MySQL from the task manager
You can't kill MySQL from the task manager or with the shutdown utility in Windows95. You must take it down with mysqladmin shutdown.
Case-insensitive names
Filenames are case insensitive on Win32, so database and table names are also case insensitive in MySQL for Win32. The only restriction is that database and table names must be given in the same case throughout a given statement. The following query would not work because it refers to a table both as my_table and as MY_TABLE: 
SELECT * FROM my_table WHERE MY_TABLE.col=1;
The `\' directory character
Pathname components in Win95 are separated by `\', which is also the escape character in MySQL. If you are using LOAD DATA INFILE or SELECT ... INTO OUTFILE, you must double the `\' character or use Unix style filenames with `/': 
SELECT * FROM skr INTO OUTFILE 'C:/tmp/skr.txt';
LOAD DATA INFILE "C:\\tmp\\skr.txt" INTO TABLE skr;
Can't open named pipe error
If you use the shareware version of MySQL-Win32 on NT with the newests mysql-clients you will get the following error: error 2017: can't open named pipe to host: . pipe... This is because the release version of MySQL uses named pipes on NT by default. You can avoid this error by using the --host=localhost option to the new MySQL clients or create a file, `C:\my.cnf', that contains the following information: 
[client]
host = localhost
If you get the error Access denied for user: 'some-user@unknown' to database 'mysql' when accessing a MySQL server on the same machine, this means that your MySQL can't resolve your host name properly. To fix this you should create a file `\windows\hosts' with the following information: 
127.0.0.1       localhost

Here are some open issues for anyone who might want to help us with the Win32 release:

Other Win32-specific issues are described in the `README' file that comes with the MySQL-Win32 distribution.

4.13 OS/2 notes

MySQL uses quite a lot of open files. Because of this you should add something like the following to your `CONFIG.SYS' file:

SET EMXOPT=-c -n -h1024

If you don't do this, you will probably run into the following error: 

File 'xxxx' not found (Errcode: 24)

4.14 TcX binaries

As a service, TcX provides a set of binary distributions of MySQL that are compiled at TcX or at sites where customers kindly have given us access to their machines.

These distributions are generated with scripts/make_binary_distribution and are configured with the following compilers and options.

SunOS 4.1.4 2 sun4c with gcc 2.7.2.1
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --disable-shared
SunOS 5.5.1 sun4u with egcs 1.0.3a
CC=gcc CFLAGS="-O6 -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-low-memory
SunOS 5.6 sun4u with egcs 2.90.27
CC=gcc CFLAGS="-O6 -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-low-memory
SunOS 5.6 i86pc with gcc 2.8.1
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-low-memory
Linux 2.0.33 i386 with pgcc 2.90.29 (egcs 1.0.3a)
CFLAGS="-O6 -mpentium -mstack-align-double -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O6 -mpentium -mstack-align-double -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static
SCO 3.2v5.0.4 i386 with gcc 2.7-95q4
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
AIX 2 4 with gcc 2.7.2.2
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
OSF1 V4.0 564 alpha with gcc 2.8.1
CC=gcc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-low-memory
IRIX 6.3 IP32 with gcc 2.8.0
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
BSDI BSD/OS 3.1 i386 with gcc 2.7.2.1
CC=gcc CXX=gcc CXXFLAGS=-O ./configure --prefix=/usr/local/mysql
BSDI BSD/OS 2.1 i386 with gcc 2.7.2
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql

Anyone who has more optimal options for any of the configurations listed above can always mail them to us at mysql-developer@tcx.se.

RPM distributions prior to MySQL 3.22 are user-contributed. Beginning with 3.22, some RPMs are TcX-generated.

4.15 Post-installation setup and testing

Once you've installed MySQL (from either a binary or source distribution), you need to initialize the grant tables, start the server and make sure that the server works okay. You may also wish to arrange for the server to be started and stopped automatically when your system starts up and shuts down.

Normally you install the grant tables and start the server like this: 

shell> ./scripts/mysql_install_db
shell> cd mysql_installation_directory
shell> ./bin/safe_mysqld &

This is described in detail below:

Testing is most easily done from the top-level directory of the MySQL distribution. For a binary distribution, this is your installation directory (typically something like `/usr/local/mysql'). For a source distribution, this is the main directory of your MySQL source tree.

In the commands shown below in this section and in the following subsections, BINDIR is the path to the location in which programs like mysqladmin and safe_mysqld are installed. For a binary distribution, this is the `bin' directory within the distribution. For a source distribution, BINDIR is probably `/usr/local/bin', unless you specified an installation directory other than `/usr/local' when you ran configure. EXECDIR is the location in which the mysqld server is installed. For a binary distribution, this is the same as BINDIR. For a source distribution, EXECDIR is probably `/usr/local/libexec'.

  1. If necessary, start the mysqld server and set up the initial MySQL grant tables containing the privileges that determine how users are allowed to connect to the server. This is normally done with the mysql_install_db script. Normally, mysql_install_db needs to be run only the first time you install MySQL. Therefore, if you are upgrading an existing installation, you can skip this step. mysql_install_db is quite safe to use and will not update any tables that already exist, so if you are unsure what to do, you can always run mysql_install_db. 
    shell> scripts/mysql_install_db
    If you don't set up the grant tables, the following error will appear in the log file when you start the server: 
    mysqld: Can't find file: 'host.frm'
    You might need to run mysql_install_db as root. However, if you prefer, you can run the MySQL server as an unprivileged (non-root) user, provided that user can read and write files in the database directory. Instructions for running MySQL as an unprivileged user are given in section 16.7 How to run MySQL as a normal user. mysql_install_db creates four tables (user, db, host and func) in the mysql database. A description of the initial privileges is given in section 6.8 Setting up the initial MySQL privileges. Briefly, the these privileges allow the MySQL root user to do anything, and allow anybody to create or use databases with a name of 'test' or starting with 'test_'. If you have problems with mysql_install_db, see section 4.15.1 Problems running mysql_install_db. There are some alternatives to running the mysql_install_db script as is: For more information about these alternatives, see section 6.8 Setting up the initial MySQL privileges.
  2. Start the MySQL server like this: 
    shell> cd mysql_installation_directory
shell> bin/safe_mysqld &
    See section 4.15.2 Problems starting the MySQL server
  3. Verify that the server is running using mysqladmin. The following commands provide a simple test to check that the server is up and responding to connections: 
    shell> BINDIR/mysqladmin version
shell> BINDIR/mysqladmin variables
    For example, the output from mysqladmin version varies slightly depending on your platform and version of MySQL, but should be similar to that shown below: 
    shell> BINDIR/mysqladmin version
mysqladmin  Ver 6.3 Distrib 3.22.9-beta, for pc-linux-gnu on i686
TCX Datakonsult AB, by Monty

Server version          3.22.9-beta
Protocol version        10
Connection              Localhost via UNIX socket
TCP port                3306
UNIX socket             /tmp/mysql.sock
Uptime:                 16 sec

Running threads: 1  Questions: 20  Reloads: 2  Open tables: 3
    To get a feeling for what else you can do with BINDIR/mysqladmin, invoke it with the --help option.
  4. Verify that you can shut down the server: 
    shell> BINDIR/mysqladmin -u root shutdown
  5. Verify that you can restart the server. Do this using safe_mysqld or by invoking mysqld directly. For example: 
    shell> BINDIR/safe_mysqld --log &
    If safe_mysqld fails, try running it from the MySQL installation directory (if you are not already there). If that doesn't work, see section 4.15.2 Problems starting the MySQL server.
  6. Run some simple tests to verify that the server is working. The output should be similar to what is shown below: 
    shell> BINDIR/mysqlshow
+-----------+
| Databases |
+-----------+
| mysql     |
+-----------+

shell> BINDIR/mysqlshow mysql
Database: mysql
+--------+
| Tables |
+--------+
| db     |
| host   |
| user   |
+--------+

shell> BINDIR/mysql -e "select host,db,user from db" mysql
+------+--------+------+
| host | db     | user |
+------+--------+------+
| %    | test   |      |
| %    | test_% |      |
+------+--------+------+
    There is also a benchmark suite in `sql-bench' that you can use to compare how MySQL performs on different platforms. In the `sql-bench/Results' directory you can find the results from many runs against different databases and platforms. To run all tests, execute these commands: 
    shell> cd sql-bench
shell> run-all-tests
    If you don't have the `sql-bench' directory, you are probably using a RPM for a binary distribution. (Source distribution RPMs include the benchmark directory.) In this case, you must first install the benchmark suite before you can use it. Beginning with MySQL 3.22, there are benchmark RPM files named `mysql-bench-VERSION-i386.rpm' that contain benchmark code and data. You can also run the tests in the `tests' subdirectory. For example, to run `auto_increment.tst', do this: 
    shell> BINDIR/mysql -vvf test < ./tests/auto_increment.tst
    The expected results are shown in the file `./tests/auto_increment.res'.

4.15.1 Problems running mysql_install_db

This section lists some of the problems you might encounter when you run mysql_install_db:

mysql_install_db doesn't install the grant tables
You may find that mysql_install_db doesn't install the grant tables, but terminates after displaying the following messages: 
starting mysqld daemon with databases from XXXXXX
mysql daemon ended
In this case, you should examine the log file very carefully! The log should be located in the directory `XXXXXX' named by the error message, and should indicate why mysqld didn't start. If you don't understand what happened, include the log when you post a bug report using mysqlbug! See section 2.3 How to report bugs or problems.
There is already a mysqld daemon running
In this case, you have probably don't have to run mysql_install_db at all. You have to run mysql_install_db only once, when you install MySQL the first time.
Installing a second mysqld daemon doesn't work when one daemon is running
This can happen when you already have an existing MySQL installation, but want to put a new installation in a different place (e.g., for testing, or perhaps you simply want to run two installations at once). Generally the problem that occurs when you try to run the second server is that it tries to use the same socket and port as the old one. In this case you will get the error message: Can't start server: Bind on TCP/IP port: Address already in use or Can't start server : Bind on unix socket... You can start the new server with a different socket and port as follows: 
shell> MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell> MYSQL_TCP_PORT=3307
shell> export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell> scripts/mysql_install_db
shell> bin/safe_mysqld &
After this, you should edit your server boot script to start both daemons with different sockets and ports. For example, it could invoke safe_mysqld twice, but with different --socket, --port and --basedir options for each invocation.
You don't have write access to `/tmp'
If you don't have write access to create a socket file at the default place (in `/tmp') or permission to create temporary files in /tmp, you will get an error when running mysql_install_db or when starting/using mysqld. You can specify a different socket and temporary directory as follows: 
shell> MYSQL_UNIX_PORT=/some_tmp_dir/mysqld.sock
shell> TMPDIR=/some_tmp_dir/
shell> export MYSQL_UNIX_PORT TMPDIR
`some_tmp_dir' should be the path to some directory for which you have write permission. After this you should be able to run mysql_install_db and start the server with: 
shell> scripts/mysql_install_db
shell> BINDIR/safe_mysqld &
mysqld crashes at once
If you are running RedHat 5.0 with a version of glibc older than 2.0.7-5, you should make sure you have installed all glibc patches! There is a lot of information about this in the MySQL mail archives. See section 4.11.4 Linux notes (all Linux versions). Links to the mail archives are available at the online MySQL documentation page. You can also start mysqld manually using the --skip-grant option and add the privilege information yourself using mysql: 
shell> BINDIR/safe_mysqld --skip-grant &
shell> BINDIR/mysql -u root mysql
From mysql, manually execute the SQL commands in mysql_install_db. Make sure you run mysqladmin reload afterward to tell the server to reload the grant tables.

4.15.2 Problems starting the MySQL server

Generally, you start the mysqld server in one of three ways:

Whichever method you use to start the server, if it fails to start up correctly, check the log file to see if you can find out why. Log files are located in the data directory (typically `/usr/local/mysql/data' for a binary distribution, `/usr/local/var' for a source distribution). Look in the data directory for a file with a name of the form `host_name.log', where host_name is the name of your server host. Then check the last few lines of that file: 

shell> tail host_name.log

When the mysqld daemon starts up, it changes directory to the data directory. This is where it expects to write log files and the pid (process ID) file, and where it expects to find databases.

The data directory location is hardwired in when the distribution is compiled. However, if mysqld expects to find the data directory somewhere other than where it really is on your system, it will not work properly. If you have problems with incorrect paths, you can find out what options mysqld allows and what the default path settings are by invoking mysqld with the --help option. You can override the defaults by specifying the correct pathnames as command-line arguments to mysqld. (These options can be used with safe_mysqld as well.)

Normally you should need to tell mysqld only the base directory under which MySQL is installed. You can do this with the --basedir option. You can also use --help to check the effect of changing path options (note that --help must be last). For example: 

shell> EXECDIR/mysqld --basedir=/usr/local --help

Once you determine the path settings you want, start the server without the --help option.

If you get the following error: 

Can't start server: Bind on TCP/IP port: Address already in use
  or
Can't start server : Bind on unix socket...

this means that some other program (or another mysqld server) is already using the TCP/IP port or socket mysqld tries to use! You should check with ps that you don't have another mysqld server running. If you can't find another server running, you can try doing telnet your-host-name tcp-ip-port-number and press RETURN a couple of times. If you don't get a error message like telnet: Unable to connect to remote host: Connection refused, something is using the TCP/IP port mysqld is trying to use. See section 4.15.1 Problems running mysql_install_db, See section 17.3 Running multiple MySQL servers on the same machine.

The safe_mysqld script is written so that it normally is able to start a server that was installed from either a source or a binary version of MySQL, even if these install the server in slightly different locations. safe_mysqld expects one of these conditions to be true:

Since safe_mysqld will try to find the server and databases relative to its own working directory, you can install a binary distribution of MySQL anywhere, as long as you start safe_mysqld from the MySQL installation directory: 

shell> cd mysql_installation_directory
shell> BINDIR/safe_mysqld &

If safe_mysqld fails, even when invoked from the MySQL installation directory, you can modify it to use the path to mysqld and the pathname options that are correct for your system. Note that if you upgrade MySQL sometime, your modified version will be overwritten, so you should make a copy of your edited version that you can reinstall.

If mysqld is currently running, you can find out what path settings it is using by executing this command: 

shell> mysqladmin variables

If safe_mysqld starts the server but you can't connect to it, you should make sure you have an entry in `/etc/hosts' that looks like this: 

127.0.0.1       localhost

This problem occurs only on systems that don't have a working thread library and for which MySQL must be configured to use MIT-pthreads.

4.15.3 Automatically starting and stopping MySQL

The mysql.server script can be used to start or stop the server, by invoking it with start or stop arguments: 

shell> mysql.server stop
shell> mysql.server start

mysql.server can be found in the `share/mysql' directory under the MySQL installation directory, or in the `support-files' directory of the MySQL source tree.

Before mysql.server starts the server, it changes directory to the MySQL installation directory, then invokes safe_mysqld. You might need to edit mysql.server if you have a binary distribution that you've installed in a non-standard location. Modify it to cd into the proper directory before it runs safe_mysqld. If you want the server to run as some specific user, you can change the mysql_daemon_user=root line to use another user. You can also modify mysql.server to pass other options to safe_mysqld.

mysql.server stop brings down server by sending a signal to it. You can take down the server manually by executing mysqladmin shutdown.

You might want to add these start and stop commands to the appropriate places in your `/etc/rc*' files when you start using MySQL for production applications. Note that if you modify mysql.server, then if you upgrade MySQL sometime, your modified version will be overwritten, so you should make a copy of your edited version that you can reinstall.

You can also add options to mysql.server in a global `/etc/my.cnf' file. A typical `/etc/my.cnf' file may look as follows: 

[mysqld]
datadir=/usr/local/mysql/var
socket=/tmp/mysqld.sock
port=3306

[mysql.server]
user=mysql
basedir=/usr/local/mysql

The mysql.server script uses the following variables: user, datadir, basedir, bindir and pid-file.

See section 4.15.4 Option files.

4.15.4 Option files

MySQL 3.22 can read default startup options for the server and for clients from option files.

MySQL reads default options from the following files on Unix:

Filename Purpose
`/etc/my.cnf' Global options
`DATADIR/my.cnf' Server-specific options
`~/.my.cnf' User-specific options

DATADIR is the MySQL data directory (typically `/usr/local/mysql/data' or `/usr/local/var'). Note that this is the directory that was specified at configuration time, not the one specified with --datadir when mysqld starts up! (The server looks for option files before it processes any command-line arguments, so --datadir has no effect on where the server looks for those files.)

MySQL reads default options from the following files on Win32:

Filename Purpose
C:\my.cnf Global options
C:\mysql\data\my.cnf Server-specific options

MySQL tries to read option files in the order listed above. If multiple option files exist, an option specified in a file read later overrides the same option specified in a file read earlier. Options specified on the command line override options specified in any option file. Some options can be specified using environment variables. Options specified on the command line or in option files override environment variable values.

The following programs support option files: mysql, mysqladmin, mysqld, mysqldump, mysqlimport, isamchk and pack_isam.

In option files, you can specify any long option that a program supports! Run the program with --help to get a list of available options.

An option file can contain lines of the following forms:

#comment
Comment lines starts with `#' or `;'. Empty lines are ignored.
[group]
group is the name of the program or group for which you want to set options. After a group line, any option or set-variable lines apply to the named group, until the end of the option file or another group line is given.
option
This is equivalent to --option on the command line.
option=value
This is equivalent to --option=value on the command line.
set-variable = variable=value
This is equivalent to --set-variable variable=value on the command line. This syntax must be used to set a mysqld variable.

The client group allows you to specify options that apply to all MySQL clients (not mysqld). This is the perfect group to use to specify the password you use to connect to the server. (But make sure the option file is readable and writable only to yourself.)

Note that for options and values, all leading and trailing blanks are automatically deleted. You may use the escape sequences `\b', `\t', `\n', `\r', `\\' and `\s' in your value string (`\s' == blank).

Here is a typical global option file: 

[client]
port=3306
socket=/tmp/mysql.sock

[mysqld]
port=3306
socket=/tmp/mysql.sock
set-variable = key_buffer=16M
set-variable = max_allowed_packet=1M

[mysqldump]
quick

Here is typical user option file: 

[client]
# The following password will be sent to all standard MySQL clients
password=my_password

[mysql]
no-auto-rehash

If you have a source distribution, you will find a sample configuration file named `my-example.cnf' in the `support-files' directory. If you have a binary distribution, look in the `DIR/share/mysql' directory, where DIR is the pathname to the MySQL installation directory (typically `/usr/local/mysql'). You can copy `my-example.cnf' to your home directory (rename the copy to `.my.cnf') to experiment with.

To tell a MySQL program not to read any option files, specify --no-defaults as the first option on the command line. This MUST be the first option or it will have no effect! If you want to check which options are used, you can give the option --print-defaults as the first option.

Note for developers: Option file handling is implemented simply by processing all matching options (i.e., options in the appropriate group) before any command line arguments. This works nicely for programs that use the last instance of an option that is specified multiple times. If you have an old program that handles multiply-specified options this way but doesn't read option files, you need add only two lines to give it that capability. Check the source code of any of the standard MySQL clients to see how to do this.

4.16 Is there anything special to do when upgrading/downgrading MySQL?

You can always move the MySQL form and data files between different versions on the same architecture as long as you have the same base version of MySQL. The current base version is 3. If you change the character set by recompiling MySQL (which may also change the sort order), you must run isamchk -r -q on all tables. Otherwise your indexes may not be ordered correctly.

If you are paranoid and/or afraid of new versions, you can always rename your old mysqld to something like mysqld-'old-version-number'. If your new mysqld then does something unexpected, you can simply shut it down and restart with your old mysqld!

When you do an upgrade you should also backup your old databases, of course. Sometimes it's good to be a little paranoid!

After an upgrade, if you experience problems with recompiled client programs, like Commands out sync or unexpected core dumps, you probably have used an old header or library file when compiling your programs. In this case you should check the date for your `mysql.h' file and `libmysql.a' library to verify that they are from the new MySQL distribution. If not, please recompile your programs!

4.16.1 Upgrading from a 3.21 version to 3.22

Nothing that affects compatibility has changed between 3.21 and 3.22. The only pitfall is that new tables that are created with DATE type columns will use the new way to store the date. You can't access these new fields from an old version of mysqld.

After installing MySQL 3.22 you should start the new server and then run the mysql_fix_privilege_tables script. This will add the new privileges that you need to use the GRANT command. If you forget this, you will get Access denied when you try to use ALTER TABLE or CREATE/DROP INDEX. If your MySQL root user requires a password, you should give this as an argument to mysql_fix_privilege_tables.

The C API interface to mysql_real_connect() has changed. If you have an old client program that calls this function, you must place a 0 for the new db argument (or recode the client to send the db element for faster connections).

4.16.2 Upgrading from a 3.20 version to 3.21

If you already have a version older than 3.20.28 running and want to switch to 3.21.x, you need to do the following:

You can start the mysqld 3.21 server with safe_mysqld --old-protocol to use it with clients from the 3.20 distribution. In this case, the new client function mysql_errno() will not return any server error, only CR_UNKNOWN_ERROR, (but it works for client errors) and the server uses the old password() checking rather than the new one.

If you are NOT using the --old-protocol option to mysqld, you will need to make the following changes:

MySQL 3.20.28 and above can handle the new user table format without affecting clients. If you have a MySQL version earlier than 3.20.28, passwords will no longer work on it if you convert the user table. So to be safe, you should first upgrade to at least 3.20.28 and then upgrade to 3.21.x.

The new client code works with a 3.20.x mysqld server, so if you experience problems with 3.21.x, you can use the old 3.20.x server without having to recompile the clients again.

If you are not using the --old-protocol option to mysqld, old clients will issue the error message: 

ERROR: Protocol mismatch. Server Version = 10 Client Version = 9

The new Perl DBI/DBD interface also supports the old mysqlperl interface. The only change you have to make if you use mysqlperl is to change the arguments to the connect() function. The new arguments are: host, database, user, password (the user and password arguments have changed places).

The following changes may affect queries in old applications:

4.16.3 Upgrading to another architecture

Currently the MySQL data and index files (`*.ISD' and `*.ISM' files) are architecture-dependent and in some case OS-dependent. If you want to move your applications to another machine that has a different architecture/OS than your current machine, you should not try to move a database by simply copying the files to the other machine. You should use mysqldump instead.

By default, mysqldump will create a file full of SQL statements. You can then transfer the file to the other machine and feed it as input to the mysql client.

Try mysqldump --help to see what options are available. If you are moving the data to a newer version of MySQL, you should use mysqldump --opt with the newer version to get a fast, compact dump.

The easiest (although not the fastest) way to move a database between two machines is to run the following commands on the machine on which the database is located: 

shell> mysqladmin -h 'other hostname' create db_name
shell> mysqldump --opt db_name \
        | mysql -h 'other hostname' db_name

If you want to copy a database from a remote machine over a slow network, you can use: 

shell> mysqladmin create db_name
shell> mysqldump -h 'other hostname' --opt --compress db_name \
        | mysql db_name

You can also store the result in a file (compressed in this example): 

shell> mysqldump --quick db_name | gzip > db_name.contents.gz

Transfer the file containing the database contents to the target machine and run these commands there: 

shell> mysqladmin create db_name
shell> gunzip < db_name.contents.gz | mysql db_name

You can also use mysqldump and mysqlimport to accomplish the database transfer. For big tables, this is much faster than simply using mysqldump. In the commands shown below, DUMPDIR represents the full pathname of the directory you use to store the output from mysqldump.

First, create the directory for the output files and dump the database: 

shell> mkdir DUMPDIR
shell> mysqldump --tab=DUMPDIR db_name

Then transfer the files in the DUMPDIR directory some corresponding directory on the target machine and load the files into MySQL there: 

shell> mysqladmin create db_name
shell> cat DUMPDIR/*.sql | mysql db_name
shell> mysqlimport db_name PATH/*.txt

Also, don't forget to copy the mysql database, since that's where the grant tables (user, db, host) are stored. You may have to run commands as the MySQL root user on the new machine until you have the mysql database in place.

After you import the mysql database on the new machine, execute mysqladmin reload so that the server reloads the grant table information.

Go to the first, previous, next, last section, table of contents.