2 Installing MySQL

This chapter describes how to obtain and install MySQL:

1. Determine whether your platform is supported. Please note that not all supported systems are equally good for running MySQL on them. On some it is much more robust and efficient than others. See section 2.1.1 Operating Systems Supported by MySQL for details.
2. Choose a distribution to install. Several versions of MySQL are available, and most are available in serveral distribution formats. You can choose from pre-packaged distributions containing binary (precompiled) programs or source code. When in doubt, use a binary distribution. We also provide public access to our current source tree, for those who want to see our most recent developments and help us test new code. To determine which version and type of distribution you should use, see section 2.1.2 Choosing Which MySQL Distribution to Install.
3. Download the distribution that you want to install. For a list of sites from which you can obtain MySQL, see section 2.1.3 How to Get MySQL. You can verify the integrity of the distribution using the instructions in section 2.1.4 Verifying Package Integrity Using MD5 Checksums or GnuPG.
4. Install the distribution. For binary distributions, use the instructions in in section 2.2.5 Installing MySQL on Other Unix-like Systems. For source distributions, use the instructions in section 2.3 MySQL Installation Using a Source Distribution. Additional installation procedures include the following:
   • For post-installation procedures, see section 2.4 Post-installation Setup and Testing. These procedures apply whether you install MySQL using a binary or source distribution.
   • If you plan to upgrade an existing version of MySQL to a newer version rather than installing MySQL for the first time, see section 2.5 Upgrading/Downgrading MySQL for information about upgrade procedures and about issues that you should consider before upgrading.
   • If you want to run the MySQL benchmark scripts, Perl support for MySQL must be available. See section 2.7 Perl Installation Notes.

The last part of the chapter provides information on system-specific problems you may run into.

2.1 General Installation Issues

Before installing MySQL, you should do the following:

1. Determine whether or not MySQL runs on your platform.
2. Choose a distribution to install.
3. Download the distribution and verify its integrity.

This section contains the information necessary to carry out these steps. After doing so, you can use the instructions in later sections of the chapter to install the distribution that you choose.

2.1.1 Operating Systems Supported by MySQL

This section lists the operating systems on which you can expect to be able to run MySQL.

We use GNU Autoconf, so it is possible to port MySQL to all modern systems that have a C++ compiler and a working implementation of POSIX threads. (Thread suport is needed for the server. To compile only the client code, the only requirement is a C++ compiler.) We use and develop the software ourselves primarily on Linux (SuSE and Red Hat), FreeBSD, and Sun Solaris (Versions 8 and 9).

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

• AIX 4.x, 5.x with native threads. See section 2.6.5.3 IBM-AIX notes.
• Amiga.
• BSDI 2.x with the MIT-pthreads package. See section 2.6.4.5 BSD/OS Version 2.x Notes.
• BSDI 3.0, 3.1 and 4.x with native threads. See section 2.6.4.5 BSD/OS Version 2.x Notes.
• DEC Unix 4.x with native threads. See section 2.6.5.5 Alpha-DEC-UNIX Notes (Tru64).
• FreeBSD 2.x with the MIT-pthreads package. See section 2.6.4.1 FreeBSD Notes.
• FreeBSD 3.x and 4.x with native threads. See section 2.6.4.1 FreeBSD Notes.
• FreeBSD 4.x with Linuxthreads. See section 2.6.4.1 FreeBSD Notes.
• HP-UX 10.20 with the DCE threads or the MIT-pthreads package. See section 2.6.5.1 HP-UX Version 10.20 Notes.
• HP-UX 11.x with the native threads. See section 2.6.5.2 HP-UX Version 11.x Notes.
• Linux 2.0+ with LinuxThreads 0.7.1+ or glibc 2.0.7+. See section 2.6.1 Linux Notes.
• Mac OS X. See section 2.6.2 Mac OS X Notes.
• NetBSD 1.3/1.4 Intel and NetBSD 1.3 Alpha (Requires GNU make). See section 2.6.4.2 NetBSD Notes.
• Novell NetWare 6.0. See section 2.2.4 Installing MySQL on NetWare.
• OpenBSD > 2.5 with native threads. OpenBSD < 2.5 with the MIT-pthreads package. See section 2.6.4.3 OpenBSD 2.5 Notes.
• OS/2 Warp 3, FixPack 29 and OS/2 Warp 4, FixPack 4. See section 2.6.6 OS/2 Notes.
• SCO OpenServer with a recent port of the FSU Pthreads package. See section 2.6.5.8 SCO Notes.
• SCO UnixWare 7.1.x. See section 2.6.5.9 SCO UnixWare Version 7.1.x Notes.
• SGI Irix 6.x with native threads. See section 2.6.5.7 SGI Irix Notes.
• Solaris 2.5 and above with native threads on SPARC and x86. See section 2.6.3 Solaris Notes.
• SunOS 4.x with the MIT-pthreads package. See section 2.6.3 Solaris Notes.
• Tru64 Unix
• Windows 9x, Me, NT, 2000, and XP. See section 2.2.1 Installing MySQL on Windows.

Not all platforms are equally well-suited for running MySQL. How well a certain platform is suited for a high-load mission-critical MySQL server is determined by the following factors:

• General stability of the thread library. A platform may have an excellent reputation otherwise, but MySQL will be only as stable as the thread library if that library is unstable in the code that is called by MySQL, even if everything else is perfect.
• The ability of the kernel and/or thread library to take advantage of symmetric multi-processor (SMP) systems. In other words, when a process creates a thread, it should be possible for that thread to run on a different CPU than the original process.
• The ability of the kernel and/or the thread library to run many threads which acquire and release a mutex over a short critical region frequently without excessive context switches. In other words, if the implementation of pthread_mutex_lock() is too anxious to yield CPU time, this will hurt MySQL tremendously. If this issue is not taken care of, adding extra CPUs will actually make MySQL slower.
• General filesystem stability and performance.
• If your tables are big, the ability of the filesystem to deal with large files at all and to deal with them efficiently.
• Our level of expertise here at MySQL AB with the platform. If we know a platform well, we enable platform-specific optimizations and fixes at compile time. We can also provide advice on configuring your system optimally for MySQL.
• The amount of testing we have done internally for similar configurations.
• The number of users that have successfully run MySQL on that platform in similar configurations. If this number is high, the chances of encountering platform-specific surprises are much smaller.

Based on the preceding criteria, the best platforms for running MySQL at this point are x86 with SuSE Linux 8.2, 2.4 kernel, and ReiserFS (or any similar Linux distribution) and SPARC with Solaris (2.7-9). FreeBSD comes third, but we really hope it will join the top club once the thread library is improved. We also hope that at some point we will be able to include into the top category all other platforms on which MySQL currently compiles and runs okay, but not quite with the same level of stability and performance. This will require some effort on our part in cooperation with the developers of the operating system and library components that MySQL depends on. If you are interested in improving one of those components, are in a position to influence its development, and need more detailed instructions on what MySQL needs to run better, send an email message to the MySQL internals mailing list. See section 1.7.1.1 The MySQL Mailing Lists.

Please note that the purpose of the preceding comparison is not to say that one operating system is better or worse than another in general. We are talking only about choosing an OS for the specific purpose of running MySQL. With this in mind, the result of this comparison would be different if we considered more factors. And in some cases, the reason one OS is better than the other could simply be that we have put forth more effort into testing on and optimizing for that particular platform. We are just stating our observations to help you decide which platform to use MySQL in your setup.

2.1.2 Choosing Which MySQL Distribution to Install

When preparing to install MySQL, you should decide which version to use. MySQL development occurs in several release series, and you can pick the one that best fits your needs. After deciding which version to install, you can choose a distribution format. Releases are available in binary or source format.

2.1.2.1 Choosing Which Version of MySQL to Install

The first decision to make is whether you want to use a production (stable) release or a development release. In the MySQL development process, multiple release series co-exist, each at a different stage of maturity:

• MySQL 5.0 is the newest development release series and is under very active development for new features. Until recently it was available only in preview form from the BitKeeper source repository. An early alpha release has now been issued to allow more widespread testing.
• MySQL 4.1 is a development release series to which major new features have been added. It is still at alpha status. Sources and binaries are available for use and testing on development systems.
• MySQL 4.0 is the current stable/production-quality release series. New releases are issued for bugfixes. No new features are added that could diminish the code stability.
• MySQL 3.23 is the old stable/production-quality release series. This series is retired, so new releases are issued only to fix critical bugs.

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.'' Naturally, relevant bugfixes from an earlier series propagate to later series.

• 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 production release series. Currently this is MySQL 4.0. Note that all MySQL releases, even those from development series, are checked with the MySQL benchmarks and an extensive test suite before being issued.
• If you are running an old system and want to upgrade, but don't want to take chances with a non-seamless upgrade, you should upgrade to the latest version in the same release series you are using (where only the last part of the version number is newer than yours). We have tried to fix only fatal bugs and make small, relatively safe changes to that version.
• If you want to use new features not present in the production release series, you can use a version from a development series. Note that development releases are not as stable as production releases.
• If you want to use the very latest sources containing all current patches and bugfixes, you can use one of our BitKeeper repositories. These are not ``releases'' as such, but are available as previews of the code on which future releases will be based.

The MySQL naming scheme uses release names that consist of three numbers and a suffix, for example, mysql-4.1.0-alpha. The numbers within the release name are is interpreted like this:

• The first number (4) is the major version and also describes the file format. All Version 4 releases have the same file format.
• The second number (1) is the release level. Taken together, the major version and release level constitute the release series number.
• The third number (0) is the version number within the release series. This is incremented for each new release. Usually you want the latest version for the series you have chosen.

For each minor update, the last number in the version string is incremented. When there are major new features or minor incompatibilities with previous versions, the second number in the version string is incremented. When the file format changes, the first number is increased.

Release names also include a suffix to indicates the stability level of the release. Releases within a series progress through a set of suffixes to indicate how the stability level improves. The possible suffixes are:

• alpha indicates that the release contains some large section of new code that hasn't been 100% tested. Known bugs (usually there are none) should be documented in the News section. See section C MySQL Change History. There are also new commands and extensions in most alpha releases. Active development that may involve major code changes can occur in an alpha release, but everything will be tested before issuing a release. For this reason, there should be no known bugs in any MySQL release.
• beta means that all new code has been tested. No major new features that could cause corruption in old code are added. There should be no known bugs. A version changes from alpha to beta when there haven't been any reported fatal bugs within an alpha version for at least a month and we have no plans to add any features that could make any old command unreliable.
• gamma is a beta that has been around a while and seems to work fine. Only minor fixes are added. This is what many other companies call a release.
• If there is no suffix, it means that the version has been run for a while at many different sites with no reports of bugs other than platform-specific bugs. Only critical bug fixes are applied to the release. This is what we call a production (stable) release.

MySQL uses a naming scheme that is slightly different from most other products. In general, it's relatively safe to use any version that has been out for a couple of weeks without being replaced with a new version within the release series.

All releases of MySQL are run through our standard tests and benchmarks to ensure that they are relatively safe to use. Because 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

The `mysql-test' directory contains an extensive set of test cases. We run these tests for virtually every server binary. See section 22.1.2 MySQL Test Suite for more information about this test suite.

The MySQL benchmark suite

This suite 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 7.1.4 The MySQL Benchmark Suite.

The crash-me test

This test tries to determine what features the database supports and what its capabilities and limitations are. See section 7.1.4 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.

2.1.2.2 Choosing a Distribution Format

After choosing which version of MySQL to install, you should decide whether to use a binary distribution or a source distribution. In most cases you should probably use a binary distribution, if one exists for your platform. Binary distributions are available in native format for many platforms, such as RPM files for Linux or DMG package installers for Mac OS X. Distributions also are available as Zip archives or compressed tar files.

Reasons to choose a binary distribution include the following:

• Binary distributions generally are easier to install than source distributions.
• To satisfy different user requirements, we provide two different binary versions: one compiled with the non-transactional storage engines (a small, fast binary), and one configured with the most important extended options like transaction-safe tables. Both versions are compiled from the same source distribution. All native MySQL clients can connect to both MySQL versions. The extended MySQL binary distribution is marked with the -max suffix and is configured with the same options as mysqld-max. See section 5.1.2 The mysqld-max Extended MySQL Server. If you want to use the MySQL-Max RPM, you must first install the standard MySQL-server RPM.

Circumstances under which you probably will be better off with a source installation include the following:

• You want to install MySQL at some explicit location. The standard binary distributions are ``ready to run'' at any place, but you may want to have even more flexibility to place MySQL components where you want.
• You want to configure mysqld with some extra features that are not in the standard binary distributions. Here is a list of the most common extra options that you may want to use:
  • --with-innodb (default for MySQL 4.0 and onwards)
  • --with-berkeley-db (not available on all platforms)
  • --with-raid
  • --with-libwrap
  • --with-named-z-libs (This is done for some of the binaries)
  • --with-debug[=full]
• You want to configure mysqld without some features that are included in the standard binary distributions. For example, distributions normally are compiled with support for all character sets. If you want a smaller MySQL server, you can recompile it with support for only the character sets you need.
• You have a special compiler (like pgcc) or want to use compiler options that are better optimized for your processor. Binary distributions are compiled with options that should work on a variety of processors from the same processor family.
• You want to use the latest sources from one of the BitKeeper repositories to have access to all current bugfixes. For example, if you have found a bug and reported it to the MySQL development team, the bugfix will be committed to the source repository and you can access it there. The bugfix will not appear in a release until a release actually is issued.
• You want to read (or modify) the C and C++ code that makes up MySQL. For this purpose, you should get a source distribution, because the source code is always the ultimate manual. Source distributions also contain more tests and examples than binary distributions.

2.1.2.3 How and When Updates Are Released

MySQL is evolving quite rapidly here at MySQL AB and we want to share new developments with other MySQL users. We try to make a release when we have very useful features that others seem to have a need for.

We also try to help out users who request features that are easy to implement. We take note of what our licensed users want to have, and we especially take note 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 C MySQL Change History.

We use the following policy when updating MySQL:

• Releases are issued within each release series. For each release, the last number in the version is one more than the previous release within the same series.
• Production (stable) releases are meant to appear about 1-2 times a year, but if small bugs are found, a release with only bug fixes will be issued.
• Working releases/bug fixes to old releases are meant to appear about every 4-8 weeks.
• Binary distributions for some platforms are made by us for major releases. Other people may make binary distributions for other systems, but probably less frequently.
• We usually make fixes available as soon as we have identified and corrected small or non-critical but annoying bugs. The fixes are available immediately from our public BitKeeper repositories, and will be included in the next release.
• If by any chance a fatal bug is found in a release, we will make a new release as soon as possible. We would like other companies to do this, too.

2.1.2.4 Release Philosophy--No Known Bugs in Releases

We put a lot of time and effort into making our releases bug free. To our knowledge, we have not released a single MySQL version with any known ``fatal'' repeatable bugs. (A fatal bug is something that crashes MySQL under normal usage, produces incorrect answers for normal queries, or has a security problem.)

We have documented all open problems, bugs, and issues that are dependent on design decisions. See section 1.8.7 Known Errors and Design Deficiencies in MySQL.

Our aim is to fix everything that is fixable without risk of making a stable MySQL version less stable. In certain cases, this means we can fix an issue in the development versions, but not in the stable (production) version. Naturally, we document such issues so that users are aware.

Here is a description of how our build process works:

• We monitor bugs from our customer support list, the bugs database at http://bugs.mysql.com/, and the MySQL external mailing lists.
• All reported bugs for live versions are entered into the bugs database.
• When we fix a bug, we always try to make a test case for it and include it into our test system to ensure that the bug will never recur without being detected. (About 90% of all fixed bugs have a test case.)
• We also create test cases for all new features we add to MySQL.
• Before we start to build a new MySQL release, we ensure that all reported repeatable bugs for the MySQL version (3.23.x, 4.0.x, etc) are fixed. If something is impossible to fix (due to some internal design decision in MySQL) we document this in the manual. See section 1.8.7 Known Errors and Design Deficiencies in MySQL.
• We do a build on all platforms for which we support binaries (15+ platforms) and run our test suite and benchmark suite on all of them.
• We will not publish a binary for a platform for which the test or benchmark suite fails. If it's a general error in the source, we fix this and do the build plus tests on all systems again, from scratch.
• The build and test process takes 2-3 days). If we receive a report regarding a fatal bug during this process (for example, one that causes a core dump), we fix the problem and restart the build process.
• After publishing the binaries on http://www.mysql.com/, we send out an announcement message to the mysql and announce mailing lists. See section 1.7.1.1 The MySQL Mailing Lists. The announcement message contains a list of all changes to the release and any known problems with the release. (The ``known problems'' section in the release notes has only been needed in a handful of releases.)
• To quickly give our users access to the latest MySQL features, we do a new MySQL release every 4-8 weeks. Source code snapshots are built daily and are available at http://downloads.mysql.com/snapshots.php.
• If we, after the release is done, get any bug reports that there was (after all) anything critically wrong with the build on a specific platform, we will fix this at once and build a new 'a' release for that platform. Thanks to our large user base, problems are found quickly.
• Our track record for making good releases is quite good. In the last 150 releases, we had to do a new build for less than 10 releases (in 3 of these cases, the bug was a faulty glibc library on one of our build machines that took us a long time to track down).

2.1.2.5 MySQL Binaries Compiled by MySQL AB

As a service, we at MySQL AB provide a set of binary distributions of MySQL that are compiled on systems at our site or on systems where supporters of MySQL kindly have given us access to their machines.

In addition to the binaries provided in platform-specific package formats (see section 2.2 Standard MySQL Installation Using a Binary Distribution), we do offer binary distributions for a number of platforms in the form of of compressed tar files (.tar.gz).

These distributions are generated using the script Build-tools/Do-compile which compiles the source code and creates the binary tar.gz archive using scripts/make_binary_distribution.

These binaries are configured and built with the following compilers and options. This information can also be obtained by looking at the variables COMP_ENV_INFO and CONFIGURE_LINE inside the script bin/mysqlbug of every binary tar file distribution.

Binaries built on MySQL AB development systems:

Linux 2.4.xx x86 with gcc 2.95.3:

CFLAGS="-O2 -mcpu=pentiumpro" CXX=gcc CXXFLAGS="-O2 -mcpu=pentiumpro -felide-constructors" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --disable-shared --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static

Linux 2.4.xx Intel Itanium 2 with ecc (Intel C++ Itanium Compiler 7.0):

CC=ecc CFLAGS="-O2 -tpp2 -ip -nolib_inline" CXX=ecc CXXFLAGS="-O2 -tpp2 -ip -nolib_inline" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile

Linux 2.4.xx Intel Itanium with ecc (Intel C++ Itanium Compiler 7.0):

CC=ecc CFLAGS=-tpp1 CXX=ecc CXXFLAGS=-tpp1 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile

Linux 2.4.xx alpha with ccc (Compaq C V6.2-505 / Compaq C++ V6.3-006):

CC=ccc CFLAGS="-fast -arch generic" CXX=cxx CXXFLAGS="-fast -arch generic -noexceptions -nortti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared --disable-shared

Linux 2.x.xx ppc with gcc 2.95.4:

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-embedded-server --with-innodb

Linux 2.4.xx s390 with gcc 2.95.3:

CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static

Linux 2.4.xx x86_64 (AMD64) with gcc 3.2.1:

CXX=gcc ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared

Sun Solaris 8 x86 with gcc 3.2.3:

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-innodb

Sun Solaris 8 SPARC with gcc 3.2:

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-z-libs=no --with-named-curses-libs=-lcurses --disable-shared

Sun Solaris 8 SPARC 64-bit with gcc 3.2:

CC=gcc CFLAGS="-O3 -m64 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -m64 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-z-libs=no --with-named-curses-libs=-lcurses --disable-shared

Sun Solaris 9 SPARC with gcc 2.95.3:

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-curses-libs=-lcurses --disable-shared

Sun Solaris 9 SPARC with cc-5.0 (Sun Forte 5.0):

CC=cc-5.0 CXX=CC ASFLAGS="-xarch=v9" CFLAGS="-Xa -xstrconst -mt -D_FORTEC_ -xarch=v9" CXXFLAGS="-noex -mt -D_FORTEC_ -xarch=v9" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-z-libs=no --enable-thread-safe-client --disable-shared

IBM AIX 4.3.2 ppc with gcc 3.2.3:

CFLAGS="-O2 -mcpu=powerpc -Wa,-many " CXX=gcc CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --disable-shared

IBM AIX 4.3.3 ppc with xlC_r (IBM Visual Age C/C++ 6.0):

CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192" CXX=xlC_r CXXFLAGS ="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --disable-shared --with-innodb

IBM AIX 5.1.0 ppc with gcc 3.3:

CFLAGS="-O2 -mcpu=powerpc -Wa,-many" CXX=gcc CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --disable-shared

IBM AIX 5.2.0 ppc with xlC_r (IBM Visual Age C/C++ 6.0):

CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192" CXX=xlC_r CXXFLAGS="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --disable-shared --with-embedded-server --with-innodb

HP-UX 10.20 pa-risc1.1 with gcc 3.1:

CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC" CXX=gcc CXXFLAGS="-DHPUX -I/opt/dce /include -felide-constructors -fno-exceptions -fno-rtti -O3 -fPIC" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-pthread --with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC --disable-shared

HP-UX 11.00 pa-risc with aCC (HP ANSI C++ B3910B A.03.50):

CC=cc CXX=aCC CFLAGS=+DAportable CXXFLAGS=+DAportable ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-embedded-server --with-innodb

HP-UX 11.11 pa-risc2.0 64bit with aCC (HP ANSI C++ B3910B A.03.33):

CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared

HP-UX 11.11 pa-risc2.0 32bit with aCC (HP ANSI C++ B3910B A.03.33):

CC=cc CXX=aCC CFLAGS="+DAportable" CXXFLAGS="+DAportable" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-innodb

HP-UX 11.22 ia64 64bit with aCC (HP aC++/ANSI C B3910B A.05.50):

CC=cc CXX=aCC CFLAGS="+DD64 +DSitanium2" CXXFLAGS="+DD64 +DSitanium2" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-embedded-server --with-innodb

Apple Mac OS X 10.2 powerpc with gcc 3.1:

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared

FreeBSD 4.7 i386 with gcc 2.95.4:

CFLAGS=-DHAVE_BROKEN_REALPATH ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-z-libs=not-used --disable-shared

FreeBSD 4.7 i386 using LinuxThreads with gcc 2.95.4:

CFLAGS="-DHAVE_BROKEN_REALPATH -D__USE_UNIX98 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads" CXXFLAGS="-DHAVE_BROKEN_REALPATH -D__USE_UNIX98 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-thread-libs="-DHAVE_GLIBC2_STYLE_GETHOSTBYNAME_R -D_THREAD_SAFE -I /usr/local/include/pthread/linuxthreads -L/usr/local/lib -llthread -llgcc_r" --disable-shared --with-embedded-server --with-innodb

QNX Neutrino 6.2.1 i386 with gcc 2.95.3qnx-nto 20010315:

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared

The following binaries are built on third-party systems kindly provided to MySQL AB by other users. Please note that these are only provided as a courtesy. Since MySQL AB does not have full control over these systems, we can provide only limited support for the binaries built on these systems.

SCO Unix 3.2v5.0.6 i386 with gcc 2.95.3:

CFLAGS="-O3 -mpentium" LDFLAGS=-static CXX=gcc CXXFLAGS="-O3 -mpentium -felide-constructors" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --enable-thread-safe-client --disable-shared

SCO OpenUnix 8.0.0 i386 with CC 3.2:

CC=cc CFLAGS="-O" CXX=CC ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --enable-thread-safe-client --disable-shared

Compaq Tru64 OSF/1 V5.1 732 alpha with cc/cxx (Compaq C V6.3-029i / DIGITAL C++ V6.1-027):

CC="cc -pthread" CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all" CXX="cxx -pthread" CXXFLAGS="-O4 -ansi_alias -fast -inline speed -speculate all -noexceptions -nortti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-prefix=/usr/local/mysql --with-named-thread-libs="-lpthread -lmach -lexc -lc" --disable-shared --with-mysqld-ldflags=-all-static

SGI Irix 6.5 IP32 with gcc 3.0.1:

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared

FreeBSD/sparc64 5.0 with gcc 3.2.1:

CFLAGS=-DHAVE_BROKEN_REALPATH ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-innodb

The following compile options have been used for binary packages MySQL AB used to provide in the past. These binaries are no longer being updated, but the compile options are listed here for reference purposes.

Linux 2.2.xx SPARC with egcs 1.1.2:

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --disable-shared

Linux 2.2.x with x686 with gcc 2.95.2:

CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static --disable-shared --with-extra-charsets=complex

SunOS 4.1.4 2 sun4c with gcc 2.7.2.1:

CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors" ./configure --prefix=/usr/local/mysql --disable-shared --with-extra-charsets=complex --enable-assembler

SunOS 5.5.1 (and above) sun4u with egcs 1.0.3a or 2.90.27 or gcc 2.95.2 and newer:

CC=gcc CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-low-memory --with-extra-charsets=complex --enable-assembler

SunOS 5.6 i86pc with gcc 2.8.1:

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-low-memory --with-extra-charsets=complex

BSDI BSD/OS 3.1 i386 with gcc 2.7.2.1:

CC=gcc CXX=gcc CXXFLAGS=-O ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex

BSDI BSD/OS 2.1 i386 with gcc 2.7.2:

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex

AIX 2 4 with gcc 2.7.2.2:

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex

Anyone who has more optimal options for any of the preceding configurations listed can always mail them to the MySQL internals mailing list. See section 1.7.1.1 The MySQL Mailing Lists.

RPM distributions prior to MySQL Version 3.22 are user-contributed. Beginning with Version 3.22, the RPM distributions are generated by us at MySQL AB.

If you want to compile a debug version of MySQL, you should add --with-debug or --with-debug=full to the preceding configure commands and remove any -fomit-frame-pointer options.

For the Windows distribution, please see section 2.2.1 Installing MySQL on Windows.

2.1.3 How to Get MySQL

Check the MySQL homepage (http://www.mysql.com/) for information about the current version and for downloading instructions.

Our main mirror is located at http://mirrors.sunsite.dk/mysql/.

For a complete up-to-date list of MySQL Web/download mirrors, see http://www.mysql.com/downloads/mirrors.html. There you will also find information about becoming a MySQL mirror site and how to report a bad or out of date mirror.

2.1.4 Verifying Package Integrity Using MD5 Checksums or GnuPG

After you have downloaded the MySQL package that suits your needs and before you attempt to install it, you should make sure it is intact and has not been tampered with.

MySQL AB offers three means of integrity checking:

• MD5 checksums
• Cryptographic signatures using GnuPG, the GNU Privacy Guard
• For RPM packages, the built-in RPM integrity verification mechanism

The following sections describe how to use these methods.

2.1.5 Verifying the MD5 Checksum

After you have downloaded the package, you should make sure that the MD5 checksum matches the one provided on the MySQL download pages. Each package has an individual checksum that you can verify with the following command, where package_name is the name of the package you downloaded:

shell> md5sum package_name

Note, that not all operating systems support the md5sum command--on some it is simply called md5, others do not ship it at all. On Linux, it is part of the GNU Text Utilities package, which is available for a wide range of platforms. You can download the source code from http://www.gnu.org/software/textutils/ as well. If you have OpenSSL installed, you can also use the command openssl md5 package_name instead. A DOS/Windows implementation of the md5 command is available from http://www.fourmilab.ch/md5/.

Example:

shell> md5sum mysql-standard-4.0.17-pc-linux-i686.tar.gz
60f5fe969d61c8f82e4f7f62657e1f06
                mysql-standard-4.0.17-pc-linux-i686.tar.gz

You should verify that the resulting checksum (the string of hexadecimal digits) matches the one displayed on the download page immediately below the respective package.

2.1.6 Signature Checking Using GnuPG

Another method of verifying the integrity and authenticity of a package is to use cryptographic signatures. This is more reliable than using MD5 checksums, but requires more work.

Beginning with MySQL 4.0.10 (February 2003), MySQL AB started signing downloadable packages with GnuPG (GNU Privacy Guard). GnuPG is an Open Source alternative to the very well-known Pretty Good Privacy (PGP) by Phil Zimmermann. See http://www.gnupg.org/ for more information about GnuPG and how to obtain and install it on your system. Most Linux distributions already ship with GnuPG installed by default. For more information about OpenPGP, see http://www.openpgp.org/.

To verify the signature for a specific package, you first need to obtain a copy of MySQL AB's public GPG build key build@mysql.com. You can either cut and paste it directly from here, or obtain it from http://www.keyserver.net/.

Key ID:
pub  1024D/5072E1F5 2003-02-03
     MySQL Package signing key (www.mysql.com) <build@mysql.com>
Fingerprint: A4A9 4068 76FC BD3C 4567  70C8 8C71 8D3B 5072 E1F5

Public Key (ASCII-armored):

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBD4+owwRBAC14GIfUfCyEDSIePvEW3SAFUdJBtoQHH/nJKZyQT7h9bPlUWC3
RODjQReyCITRrdwyrKUGku2FmeVGwn2u2WmDMNABLnpprWPkBdCk96+OmSLN9brZ
fw2vOUgCmYv2hW0hyDHuvYlQA/BThQoADgj8AW6/0Lo7V1W9/8VuHP0gQwCgvzV3
BqOxRznNCRCRxAuAuVztHRcEAJooQK1+iSiunZMYD1WufeXfshc57S/+yeJkegNW
hxwR9pRWVArNYJdDRT+rf2RUe3vpquKNQU/hnEIUHJRQqYHo8gTxvxXNQc7fJYLV
K2HtkrPbP72vwsEKMYhhr0eKCbtLGfls9krjJ6sBgACyP/Vb7hiPwxh6rDZ7ITnE
kYpXBACmWpP8NJTkamEnPCia2ZoOHODANwpUkP43I7jsDmgtobZX9qnrAXw+uNDI
QJEXM6FSbi0LLtZciNlYsafwAPEOMDKpMqAK6IyisNtPvaLd8lH0bPAnWqcyefep
rv0sxxqUEMcM3o7wwgfN83POkDasDbs3pjwPhxvhz6//62zQJ7Q7TXlTUUwgUGFj
a2FnZSBzaWduaW5nIGtleSAod3d3Lm15c3FsLmNvbSkgPGJ1aWxkQG15c3FsLmNv
bT6IXQQTEQIAHQUCPj6jDAUJCWYBgAULBwoDBAMVAwIDFgIBAheAAAoJEIxxjTtQ
cuH1cY4AnilUwTXn8MatQOiG0a/bPxrvK/gCAJ4oinSNZRYTnblChwFaazt7PF3q
zIhMBBMRAgAMBQI+PqPRBYMJZgC7AAoJEElQ4SqycpHyJOEAn1mxHijft00bKXvu
cSo/pECUmppiAJ41M9MRVj5VcdH/KN/KjRtW6tHFPYhMBBMRAgAMBQI+QoIDBYMJ
YiKJAAoJELb1zU3GuiQ/lpEAoIhpp6BozKI8p6eaabzF5MlJH58pAKCu/ROofK8J
Eg2aLos+5zEYrB/LsrkCDQQ+PqMdEAgA7+GJfxbMdY4wslPnjH9rF4N2qfWsEN/l
xaZoJYc3a6M02WCnHl6ahT2/tBK2w1QI4YFteR47gCvtgb6O1JHffOo2HfLmRDRi
Rjd1DTCHqeyX7CHhcghj/dNRlW2Z0l5QFEcmV9U0Vhp3aFfWC4Ujfs3LU+hkAWzE
7zaD5cH9J7yv/6xuZVw411x0h4UqsTcWMu0iM1BzELqX1DY7LwoPEb/O9Rkbf4fm
Le11EzIaCa4PqARXQZc4dhSinMt6K3X4BrRsKTfozBu74F47D8Ilbf5vSYHbuE5p
/1oIDznkg/p8kW+3FxuWrycciqFTcNz215yyX39LXFnlLzKUb/F5GwADBQf+Lwqq
a8CGrRfsOAJxim63CHfty5mUc5rUSnTslGYEIOCR1BeQauyPZbPDsDD9MZ1ZaSaf
anFvwFG6Llx9xkU7tzq+vKLoWkm4u5xf3vn55VjnSd1aQ9eQnUcXiL4cnBGoTbOW
I39EcyzgslzBdC++MPjcQTcA7p6JUVsP6oAB3FQWg54tuUo0Ec8bsM8b3Ev42Lmu
QT5NdKHGwHsXTPtl0klk4bQk4OajHsiy1BMahpT27jWjJlMiJc+IWJ0mghkKHt92
6s/ymfdf5HkdQ1cyvsz5tryVI3Fx78XeSYfQvuuwqp2H139pXGEkg0n6KdUOetdZ
Whe70YGNPw1yjWJT1IhMBBgRAgAMBQI+PqMdBQkJZgGAAAoJEIxxjTtQcuH17p4A
n3r1QpVC9yhnW2cSAjq+kr72GX0eAJ4295kl6NxYEuFApmr1+0uUq/SlsQ==
=YJkx
-----END PGP PUBLIC KEY BLOCK-----

You can import this key into your personal public GPG keyring by using gpg --import. See the GPG documentation for more info on how to work with public keys.

After you have downloaded and imported the public build key, download your desired MySQL package and the corresponding signature, which also is available from the download page. The signature file has the same name as the distribution file with an `.asc' extension. For example:

Make sure that both files are stored in the same directory and then run the following command to verify the signature for the distribution file:

shell> gpg --verify package_name.asc

Example:

shell> gpg --verify mysql-standard-4.0.17-pc-linux-i686.tar.gz.asc
gpg: Warning: using insecure memory!
gpg: Signature made Mon 03 Feb 2003 08:50:39 PM MET using DSA key ID 5072E1F5
gpg: Good signature from
     "MySQL Package signing key (www.mysql.com) <build@mysql.com>"

The ``Good signature'' message indicates that everything is all right.

2.1.7 Signature Checking Using RPM

For RPM packages, there is no separate signature. RPM packages actually have a built-in GPG signature and MD5 checksum. You can verify a package by running the following command:

shell> rpm --checksig package_name.rpm

Example:

shell> rpm --checksig MySQL-server-4.0.10-0.i386.rpm
MySQL-server-4.0.10-0.i386.rpm: md5 gpg OK

Note: If you are using RPM 4.1 and it complains about (GPG) NOT OK (MISSING KEYS: GPG#5072e1f5) (even though you have imported it into your own GPG public keyring), you need to import the key into the RPM keyring first. RPM 4.1 no longer uses your personal GPG keyring (and GPG itself), but rather maintains its own keyring (because it's a system-wide application and a user's GPG public keyring is a user-specific file). To import the MySQL public key into the RPM keyring, use rpm --import.

For example, if you have the public key stored in a file named `mysql_pubkey.asc', import it using this command:

shell> rpm --import mysql_pubkey.asc

If you notice that the MD5 checksum or GPG signatures do not match, first try to download the respective package one more time, perhaps from another mirror site. If you repeatedly cannot successfully verify the integrity of the package, please notify us about such incidents including the full package name and the download site you have been using at webmaster@mysql.com or build@mysql.com. Do not report downloading problems using the bug-reporting system.

2.1.8 Installation Layouts

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

On Windows, the default installation directory is `C:\mysql', which has the following subdirectories:

Installations created from Linux RPM distributions result in files under the following system directories:

On Unix, a tar file binary distribution is installed by unpacking it at the installation location you choose (typically `/usr/local/mysql') and creates the following directories in that location:

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:

Within an installation directory, the layout of a source installation differs from that of a binary installation in the following ways:

• The mysqld server is installed in the `libexec' directory rather than in the `bin' directory.
• The data directory is `var' rather than `data'.
• mysql_install_db is installed in the `bin' directory rather than in the `scripts' directory.
• The header file and library directories are `include/mysql' and `lib/mysql' rather than `include' and `lib'.

You can create your own binary installation from a compiled source distribution by executing the `scripts/make_binary_distribution' script from the top directory of the source distribution.

2.2 Standard MySQL Installation Using a Binary Distribution

This section covers the installation of MySQL on platforms where we offer packages using the native packaging format of the respective platform. (This is also known as performing a ``binary install.'') However, binary distributions of MySQL are available for many other platforms as well. See section 2.2.5 Installing MySQL on Other Unix-like Systems for generic installation instructions for these packages that apply to all platforms.

See section 2.1 General Installation Issues for more information on what other binary distributions are available and how to obtain them.

2.2.1 Installing MySQL on Windows

The installation process for MySQL on Windows has the following steps:

1. Install the distribution.
2. Set up an option file if necessary.
3. Select the server you want to use.
4. Start the server.
5. Assign passwords to the initial MySQL accounts.

MySQL for Windows is available in two distribution formats:

• The binary distribution contains a setup program that installs everything you need so that you can start the server immediately.
• The source distribution contains all the code and support files for building the executables using the VC++ 6.0 compiler.

Generally speaking, you should use the binary distribution. It's simpler, and you need no additional tools to get MySQL up and running.

This section describes how to install MySQL on Windows using a binary distribution. To install using a source distribution, see section 2.3.6 Installing MySQL from Source on Windows.

2.2.1.1 Windows System Requirements

To run MySQL on Windows, you need the following:

• A 32-bit Windows operating system such as 9x, Me, NT, 2000, or XP. The NT family (Windows NT, 2000, and XP) permits you to run the MySQL server as a service. See section 2.2.1.7 Starting MySQL as a Windows Service.
• TCP/IP protocol support.
• A copy of the MySQL binary distribution for Windows, which can be downloaded from http://www.mysql.com/downloads/. Note: The distribution files are supplied with a zipped format and we recommend the use of an adequate FTP client with resume feature to avoid corruption of files during the download process.
• A ZIP program to unpack the distribution file.
• Enough space on the hard drive to unpack, install, and create the databases in accordance with your requirements.
• If you plan to connect to the MySQL server via ODBC, you also need the MyODBC driver. See section 20.3 MySQL ODBC Support.
• If you need tables with a size larger than 4GB, install MySQL on an NTFS or newer filesystem. Don't forget to use MAX_ROWS and AVG_ROW_LENGTH when you create tables. See section 14.2.5 CREATE TABLE Syntax.

2.2.1.2 Installing a Windows Binary Distribution

To install MySQL on Windows using a binary distribution, follow this procedure:

1. If you are working on a Windows NT, 2000, or XP machine, make sure you have logged in as a user with administrator privileges.
2. If you are doing an upgrade of an earlier MySQL installation, it is necessary to stop the current server. On Windows NT, 2000, or XP machines, if you are running the server as a Windows service, stop it as follows from the command prompt:

   C:\> NET STOP MySQL
   

   If you plan to use a different server after the upgrade (for example, if you want to run mysqld-max rather than mysqld), remove the existing service:

   C:\mysql\bin> mysqld --remove
   

   You can reinstall the service to use the proper server after upgrading. If you are not running the MySQL server as a service, stop it like this:

   C:\mysql\bin> mysqladmin -u root shutdown
   

3. Exit the WinMySQLAdmin program if it is running.
4. Unzip the distribution file to a temporary directory.
5. Run the setup.exe program to begin the installation process. If you want to install MySQL into a location other than the default directory (`C:\mysql'), use the Browse button to specify your preferred directory. If you do not install MySQL into the default location, you will need to specify the location whenever you start the server. The easiest way to do this is to use an option file, as described in section 2.2.1.3 Preparing the Windows MySQL Environment.
6. Finish the install process.

Important note: Early alpha Windows distributions for MySQL 4.1 do not contain any installer program. A 4.1 distribution is a ZIP file that you just unzip in the location where you want to install MySQL. For example, to install `mysql-4.1.1-alpha-win.zip' as `C:\mysql', unzip the distribution file on the C: drive, then rename the resulting `mysql-4.1.1-alpha' directory to `mysql'.

If you are upgrading to MySQL 4.1 from an earlier version, you will want to preserve your existing `data' directory that contains the grant tables in the mysql database and your own databases. Before installing 4.1, stop the server if it is running, and save your `data' directory to another location. Then either rename the existing `C:\mysql' directory or remove it. Install 4.1 as described in the preceding paragraph, and then replace its `data' directory with your old `data' directory. Start the new server and update the grant tables. This will avoid loss of your current databases. See section 2.5.8 Upgrading the Grant Tables.

2.2.1.3 Preparing the Windows MySQL Environment

If you need to specify startup options when you run the server, you can indicate them on the command line or place them in an option file. For options that will be used every time the server starts, you will find it most convenient to use an option file to specify your MySQL configuration. This is true particularly under the following circumstances:

• The installation or data directory locations are different from the default locations (`C:\mysql' and `C:\mysql\data').
• You need to tune the server settings. For example, to use the InnoDB transactional tables in MySQL version 3.23, you must manually create two new directories to hold the InnoDB data and log files--such as, `C:\ibdata' and `C:\iblogs'. You will also need to add some extra lines to the option file, as described in section 16.4 InnoDB Configuration. (As of MySQL 4.0, InnoDB creates its datafiles and log files in the data directory by default. This means you need not configure InnoDB explicitly. You may still do so if you wish, and an option file will be useful in this case, too.)

On Windows, the MySQL installer places the data directory directly under the directory where you install MySQL. If you would like to use a data directory in a different location, you should copy the entire contents of the `data' directory to the new location. For example, by default, the installer places MySQL in `C:\mysql' and the data directory in `C:\mysql\data'. If you want to use a data directory of `E:\mydata', you must do two things:

• Move the data directory from `C:\mysql\data' to `E:\mydata'.
• Use a --datadir option to specify the new data directory location each time you start the server.

When the MySQL server starts on Windows, it looks for options in two files: The `my.ini' file in the Windows directory, and the `C:\my.cnf' file. The Windows directory typically is named something like `C:\WINDOWS' or `C:\WinNT'. You can determine its exact location from the value of the WINDIR environment variable using the following command:

C:\> echo %WINDIR%

MySQL looks for options first in the `my.ini' file, then in the `my.cnf' file. However, to avoid confusion, it's best if you use only one file. If your PC uses a boot loader where the C: drive isn't the boot drive, your only option is to use the `my.ini' file. Whichever one you use, it must be a plain text file.

An option file can be created and modified with any text editor, such as the Notepad program. For example, if MySQL is installed at `D:\mysql' and the data directory is located as `D:\mydata\data', you can create the option file and set up a [mysqld] section to specify values for the basedir and datadir parameters:

[mysqld]
# set basedir to your installation path
basedir=D:/mysql
# set datadir to the location of your data directory
datadir=D:/mydata/data

Note that Windows pathnames are specified in option files using forward slashes rather than backslashes. If you do use backslashes, you must double them.

Another way to manage an option file is to use the WinMySQLAdmin tool. You can find WinMySQLAdmin in the `bin' directory of your MySQL installation, as well as a help file containing instructions for using it. WinMySQLAdmin has the capability of editing your option file, but note these points:

• WinMySQLAdmin uses only the `my.ini' file.
• If WinMySQLAdmin finds a `C:\my.cnf' file, it will in fact rename it to `C:\my_cnf.bak' to disable it.

Now you are ready to test starting the server.

2.2.1.4 Selecting a Windows Server

Starting with MySQL 3.23.38, the Windows distribution includes both the normal and the MySQL-Max server binaries. Here is a list of the different MySQL servers from which you can choose:

All of the preceding binaries are optimized for modern Intel processors but should work on any Intel i386-class or higher processor.

MySQL supports TCP/IP on all Windows platforms. The mysqld-nt and mysql-max-nt servers support named pipes on NT, 2000, and XP. However, the default is to use TCP/IP regardless of the platform. (Named pipes are slower than TCP/IP in many Windows configurations.)

Named pipe use is subject to these conditions:

• Starting from MySQL 3.23.50, named pipes are enabled only if you start the server with the --enable-named-pipe option. It is now necessary to use this option explicitly because some users have experienced problems shutting down the MySQL server when named pipes are used.
• Named pipe connections are allowed only by the mysqld-nt or mysqld-max-nt servers, and only if the server is run on a version of Windows that supports named pipes (NT, 2000, XP).
• These servers can be run on Windows 98 or Me, but only if TCP/IP is installed; named pipe connections cannot be used.
• On Windows 95, these servers cannot be used.

2.2.1.5 Starting the Server for the First Time

On Windows 95, 98, or Me, MySQL clients always connect to the server using TCP/IP. (This will allow any machine on your network to connect to your MySQL server.) Because of this, you must make sure that TCP/IP support is installed on your machine before starting MySQL. You can find TCP/IP on your Windows CD-ROM.

Note that if you are using an old Windows 95 release (for example, OSR2), it's likely that you have an old Winsock package; MySQL requires Winsock 2! You can get the newest Winsock from http://www.microsoft.com/. Windows 98 has the new Winsock 2 library, so it is unnecessary to update the library.

On NT-based systems such as Windows NT, 2000, or XP, clients have two options. They can use TCP/IP, or they can use a named pipe if the server supports named pipe connections.

For information about which server binary to run, see section 2.2.1.3 Preparing the Windows MySQL Environment.

This section gives a general overview of starting the MySQL server. The following sections provide more specific information for particular versions of Windows.

The examples in these sections assume that MySQL is installed under the default location of `C:\mysql'. Adjust the pathnames shown in the examples if you have MySQL installed in a different location.

Testing is best done from a command prompt in a console window (a ``DOS window''). This way you can have the server display status messages in the window where they are easy to see. If something is wrong with your configuration, these messages will make it easier for you to identify and fix any problems.

Make sure you are in the directory where the server is located, then enter this command:

C:\mysql\bin> mysqld --console

For servers that include InnoDB support, you should see the following messages as the server starts:

InnoDB: The first specified datafile c:\ibdata\ibdata1 did not exist:
InnoDB: a new database to be created!
InnoDB: Setting file c:\ibdata\ibdata1 size to 209715200
InnoDB: Database physically writes the file full: wait...
InnoDB: Log file c:\iblogs\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file c:\iblogs\ib_logfile0 size to 31457280
InnoDB: Log file c:\iblogs\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file c:\iblogs\ib_logfile1 size to 31457280
InnoDB: Log file c:\iblogs\ib_logfile2 did not exist: new to be created
InnoDB: Setting log file c:\iblogs\ib_logfile2 size to 31457280
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: creating foreign key constraint system tables
InnoDB: foreign key constraint system tables created
011024 10:58:25  InnoDB: Started

When the server finishes its startup sequence, you should see something like this, which indicates that the server is ready to service client connections:

mysqld: ready for connections
Version: '4.0.14-log'  socket: ''  port: 3306

The server will continue to write to the console any further diagnostic output it produces. You can open a new console window in which to run client programs.

If you omit the --console option, the server writes diagnostic output to the error log in the data directory. The error log is the file with the `.err' extension.

The accounts that are listed in the MySQL grant tables initially have no passwords. After starting the server, you should set up passwords for them using the instructions in section 2.4 Post-installation Setup and Testing.

2.2.1.6 Starting MySQL from the Windows Command Line

The MySQL server can be started manually from the command line. This can be done on any version of Windows.

To start the mysqld server from the command line, you should start a console window (a ``DOS'' window) and enter this command:

shell> C:\mysql\bin\mysqld

On non-NT versions of Windows, this will start mysqld in the background. That is, after the server starts, you should see another command prompt. If you start the server this way on Windows NT, 2000, or XP, the server will run in the foreground and no command prompt will appear until the server exits. Because of this, you should open another console window to run client programs while the server is running.

You can stop the MySQL server by executing this command:

shell> C:\mysql\bin\mysqladmin -u root shutdown

This invokes the MySQL administrative utility mysqladmin to connect to the server and tell it to shut down. The command connects as root, which is the default administrative account in the MySQL grant system. Please note that users in the MySQL grant system are wholly independent from any login users under Windows.

If mysqld doesn't start, check the error log to see whether the server wrote any messages there to indicate the cause of the problem. The error log is located in the `C:\mysql\data' directory. It is the file with a suffix of `.err'. You can also try to start the server as mysqld --console; in this case, you may get some useful information on the screen that may help solve the problem.

The last option is to start mysqld with --standalone --debug. In this case mysqld will write a log file `C:\mysqld.trace' that should contain the reason why mysqld doesn't start. See section D.1.2 Creating Trace Files.

Use mysqld --help to display all the options that mysqld understands!

2.2.1.7 Starting MySQL as a Windows Service

On the NT family (Windows NT, 2000, or XP), the recommended way to run MySQL is to install it as a Windows service. Then Windows starts and stops the MySQL server automatically when Windows starts and stops. A server installed as a service can also be controlled from the command line using NET commands, or with the graphical Services utility.

The Services utility (the Windows Service Control Manager) can be found in the Windows Control Panel (under Administrative Tools on Windows 2000). It is advisable to close the Services utility while performing server installation or removal operations from this command line. This prevents some odd errors.

To get MySQL to work with TCP/IP on Windows NT 4, you must install service pack 3 (or newer)!

Before installing MySQL as a Windows service, you should first stop the current server if it is running by using the following command:

shell> C:\mysql\bin\mysqladmin -u root shutdown

This invokes the MySQL administrative utility mysqladmin to connect to the server and tell it to shut down. The command connects as root, which is the default administrative account in the MySQL grant system. Please note that users in the MySQL grant system are wholly independent from any login users under Windows.

Now install the server as a service:

shell> mysqld --install

If you have problems installing mysqld as a service using just the server name, try installing it using its full pathname:

shell> C:\mysql\bin\mysqld --install

As of MySQL 4.0.2, you can specify a specific service name after the --install option. As of MySQL 4.0.3, you can in addition specify a --defaults-file option after the service name to indicate where the server should obtain options when it starts. The rules that determine the service name and option files the server uses are as follows:

• If you specify no service name, the server uses the default service name of MySQL and the server reads options from the [mysqld] group in the standard option files.
• If you specify a service name after the --install option, the server ignores the [mysqld] option group and instead reads options from the group that has the same name as the service. The server reads options from the standard option files.
• If you specify a --defaults-file option after the service name, the server ignores the standard option files and reads options only from the [mysqld] group of the named file.

Note: Prior to MySQL 4.0.17, a server installed as a Windows service has problems starting if its pathname or the service name contains spaces. For this reason, avoid installing MySQL in a directory such as `C:\Program Files' or using a service name containing spaces.

In the usual case that you install the server with --install but no service name, the server is installed with a service name of MySQL.

As a more complex example, consider the following command (which should be entered on a single line):

shell> C:\mysql\bin\mysqld --install mysql
           --defaults-file=C:\my-opts.cnf

Here, a service name is given after the --install option. If no --defaults-file option had been given, this command would have the effect of causing the server to read the [mysql] group from the standard option files. (This would be a bad idea, because that option group is for use by the mysql client program.) However, because the --defaults-file option is present, the server reads options only from the named file, and only from the [mysqld] option group.

You can also specify options as ``Start parameters'' in the Windows Services utility before you start the MySQL service.

Once a MySQL server is installed as a service, Windows will start the service automatically whenever Windows starts. The service also can be started immediately from the Services utility, or by using the command NET START MySQL. The NET command is not case sensitive.

Please note that when run as a service, mysqld has no access to a console window, so no messages can be seen there. If mysqld doesn't start, check the error log to see whether the server wrote any messages there to indicate the cause of the problem. The error log is located in the `C:\mysql\data' directory. It is the file with a suffix of `.err'.

When mysqld is running as a service, it can be stopped by using the Services utility, the command NET STOP MySQL, or the command mysqladmin shutdown. If the service is running when Windows shuts down, Windows will stop the server automatically.

From MySQL version 3.23.44, you have the choice of installing the server as a Manual service if you don't wish the service to be started automatically during the boot process. To do this, use the --install-manual option rather than the --install option:

shell> C:\mysql\bin\mysqld --install-manual

To remove a server that is installed as a service, first stop it if it is running. Then use the --remove option to remove it:

shell> mysqld --remove

For MySQL versions older than 3.23.49, one problem with automatic MySQL service shutdown is that Windows waited only for a few seconds for the shutdown to complete, then killed the database server process if the time limit was exceeded. This had the potential to cause problems. (For example, the InnoDB storage engine had to perform crash recovery at the next startup.) Starting from MySQL version 3.23.49, Windows waits longer for the MySQL server shutdown to complete. If you notice this still is not enough for your installation, it is safest not to run the MySQL server as a service. Instead, start it from the command-line prompt, and stop it with mysqladmin shutdown.

This change to tell Windows to wait longer when stopping the MySQL server works for Windows 2000 and XP. It does not work for Windows NT, where Windows waits only 20 seconds for a service to shut down, and after that kills the service process. You can increase this default by opening the Registry Editor `\winnt\system32\regedt32.exe' and editing the value of WaitToKillServiceTimeout at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control in the Registry tree. Specify the new larger value in milliseconds. For example, the value 120000 tells Windows NT to wait up to 120 seconds.

If you don't want to start mysqld as a service, you can start it from the command line the same way as for versions of Windows that are not based on NT. For instructions, see section 2.2.1.6 Starting MySQL from the Windows Command Line.

2.2.1.8 Running MySQL Client Programs on Windows

You can test whether the MySQL server is working by executing any of the following commands:

C:\> C:\mysql\bin\mysqlshow
C:\> C:\mysql\bin\mysqlshow -u root mysql
C:\> C:\mysql\bin\mysqladmin version status proc
C:\> C:\mysql\bin\mysql test

If mysqld is slow to respond to TCP/IP connections from client programs on Windows 9x/Me, there is probably a problem with your DNS. In this case, start mysqld with the --skip-name-resolve option and use only localhost and IP numbers in the Host column of the MySQL grant tables.

You can force a MySQL client to use a named pipe connection rather than TCP/IP by specifying the --pipe option or by specifying . (period) as the host name. Use the --socket option to specify the name of the pipe. In MySQL 4.1, you should use the --protocol=PIPE option.

There are two versions of the MySQL command-line tool:

If you want to use mysqlc, you must have a copy of the `cygwinb19.dll' library installed somewhere that mysqlc can find it. Current distributions of MySQL include this library in the same directory as mysqlc (the `bin' directory under the base directory of your MySQL installation). If your distribution does not have the cygwinb19.dll library in the `bin' directory, look for it in the lib directory and copy it to your Windows system directory (`\Windows\system' or similar place).

2.2.1.9 MySQL on Windows Compared to MySQL on Unix

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

Windows 95 and threads

Windows 95 leaks about 200 bytes of main memory for each thread creation. Each connection in MySQL creates a new thread, so you shouldn't run mysqld for an extended time on Windows 95 if your server handles many connections! Other versions of Windows don't suffer from this bug.

Limited number of ports

Windows systems have about 4,000 ports available for client connections, and after a connection on a port closes, it takes two to four minutes before the port can be reused. In situations where clients connect to and disconnect from the server at a high rate, it is possible for all available ports to be used up before closed ports become available again. If this happens, the MySQL server will appear to have become unresponsive even though it is running. Note that ports may be used by other applications running on the machine as well, in which case the number of ports available to MySQL is lower.

Concurrent reads

MySQL depends on the pread() and pwrite() calls to be able to mix INSERT and SELECT. Currently we use mutexes to emulate pread()/pwrite(). We will, in the long run, replace the file level interface with a virtual interface so that we can use the readfile()/writefile() interface on NT, 2000, and XP to get more speed. The current implementation limits the number of open files MySQL can use to 1024, which means that you will not be able to run as many concurrent threads on NT, 2000, and XP as on Unix.

Blocking read

MySQL uses a blocking read for each connection, which has the following implications:

• A connection will not be disconnected automatically after eight hours, as happens with the Unix version of MySQL.
• If a connection hangs, it's impossible to break it without killing MySQL.
• mysqladmin kill will not work on a sleeping connection.
• mysqladmin shutdown can't abort as long as there are sleeping connections.

We plan to fix this problem when our Windows developers have figured out a nice workaround.

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 Windows 95. You must take it down with mysqladmin shutdown.

Case-insensitive names

Filenames are not case sensitive on Windows, so MySQL database and table names are also not case sensitive on Windows. The only restriction is that database and table names must be specified using the same case throughout a given statement. See section 10.2.2 Identifier Case Sensitivity.

The `\' pathname separator character

Pathname components in Windows 95 are separated by the `\' character, which is also the escape character in MySQL. If you are using LOAD DATA INFILE or SELECT ... INTO OUTFILE, use Unix style filenames with `/' characters:

mysql> LOAD DATA INFILE 'C:/tmp/skr.txt' INTO TABLE skr;
mysql> SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;

Alternatively, you must double the `\' character:

mysql> LOAD DATA INFILE 'C:\\tmp\\skr.txt' INTO TABLE skr;
mysql> SELECT * INTO OUTFILE 'C:\\tmp\\skr.txt' FROM skr;

Problems with pipes.

Pipes don't work reliably from the Windows command-line prompt. If the pipe includes the character ^Z / CHAR(24), Windows will think it has encountered end-of-file and abort the program. This is mainly a problem when you try to apply a binary log as follows:

C:\> mysqlbinlog binary-log-name | mysql --user=root

If you get a problem applying the log and suspect it's because of an ^Z / CHAR(24) character you can use the following workaround:

C:\> mysqlbinlog binary-log-file --result-file=/tmp/bin.sql
C:\> mysql --user=root --execute "source /tmp/bin.sql"

The latter command also can be used to reliably read in any SQL file that may contain binary data.

Can't open named pipe error

If you use a MySQL Version 3.22 server on NT with the newest MySQL client programs, you will get the following error:

error 2017: can't open named pipe to host: . pipe...

This happens 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 an option file `C:\my.cnf' that contains the following information:

[client]
host = localhost

Starting from 3.23.50, named pipes are enabled only if mysqld-nt or mysqld-max-nt is started with --enable-named-pipe.

Access denied for user error

If you attempt to run a MySQL client program to connect to a server running on the same machine, but get the error Access denied for user: 'some-user@unknown' to database 'mysql', this means that MySQL can't resolve your hostname properly. To fix this, you should create a file `\windows\hosts' with the following information:

127.0.0.1       localhost

ALTER TABLE

While you are executing an ALTER TABLE statement, the table is locked from being used by other threads. This has to do with the fact that on Windows, you can't delete a file that is in use by another threads. In the future, we may find some way to work around this problem.

DROP TABLE

DROP TABLE on a table that is in use by a MERGE table will not work on Windows because the MERGE handler does the table mapping hidden from the upper layer of MySQL. Because Windows doesn't allow you to drop files that are open, you first must flush all MERGE tables (with FLUSH TABLES) or drop the MERGE table before dropping the table. We will fix this at the same time we introduce views.

DATA DIRECTORY and INDEX DIRECTORY

The DATA DIRECTORY and INDEX DIRECTORY options for CREATE TABLE are ignored on Windows, because Windows doesn't support symbolic links. These options also are ignored on systems that have a non-functional realpath() call.

Here are some open issues for anyone who might want to help us improve MySQL on Windows:

• Add some nice start and shutdown icons to the MySQL installation.
• It would be really nice to be able to kill mysqld from the Task Manager. For the moment, you must use mysqladmin shutdown.
• Port readline to Windows for use in the mysql command-line tool.
• GUI versions of the standard MySQL clients (mysql, mysqlshow, mysqladmin, and mysqldump) would be nice.
• It would be nice if the socket read and write functions in `net.c' were interruptible. This would make it possible to kill open threads with mysqladmin kill on Windows.
• Add macros to use the faster thread-safe increment/decrement methods provided by Windows.

2.2.2 Installing MySQL on Linux

The recommended way to install MySQL on Linux is by using the RPM packages. The MySQL RPMs are currently built on a SuSE Linux 7.3 system but should work on most versions of Linux that support rpm and use glibc.

Note: RPM distributions of MySQL often are provided by other vendors. Be aware that they may differ in features and capabilities from those built by MySQL AB, and that the instructions in this manual do not necessarily apply to installing them. The vendor's instructions should be consulted instead.

If you have problems with an RPM file (for example, if you receive the error ``Sorry, the host 'xxxx' could not be looked up''), see section 2.6.1.2 Linux Binary Distribution Notes.

In most cases, you only need to install the MySQL-server and MySQL-client packages to get a functional MySQL installation. The other packages are not required for a standard installation. If you want to run a MySQL-Max server that has additional capabilities, you should install the MySQL-Max RPM. However, you should do so only after installing the MySQL-server RPM. See section 5.1.2 The mysqld-max Extended MySQL Server.

If you get a dependency failure when trying to install the MySQL 4.0 packages (for example, ``error: removing these packages would break dependencies: libmysqlclient.so.10 is needed by ...''), you should also install the package MySQL-shared-compat, which includes both the shared libraries for backward compatibility (libmysqlclient.so.12 for MySQL 4.0 and libmysqlclient.so.10 for MySQL 3.23).

Many Linux distributions still ship with MySQL 3.23 and they usually link applications dynamically to save disk space. If these shared libraries are in a separate package (for example, MySQL-shared), it is sufficient to simply leave this package installed and just upgrade the MySQL server and client packages (which are statically linked and do not depend on the shared libraries). For distributions that include the shared libraries in the same package as the MySQL server (for example, Red Hat Linux), you could either install our 3.23 MySQL-shared RPM, or use the MySQL-shared-compat package instead.

The following RPM packages are available:

• MySQL-server-VERSION.i386.rpm The MySQL server. You will need this unless you only want to connect to a MySQL server running on another machine. Please note: Server RPM files were called MySQL-VERSION.i386.rpm before MySQL 4.0.10. That is, they did not have -server in the name.
• MySQL-Max-VERSION.i386.rpm The MySQL-Max server. This server has additional capabilities that the one provided in the MySQL-server RPM does not. You must install the MySQL-server RPM first, because the MySQL-Max RPM depends on it.
• MySQL-client-VERSION.i386.rpm The standard MySQL client programs. You probably always want to install this package.
• MySQL-bench-VERSION.i386.rpm Tests and benchmarks. Requires Perl and the DBD::mysql module.
• MySQL-devel-VERSION.i386.rpm The libraries and include files that are needed if you want to compile other MySQL clients, such as the Perl modules.
• MySQL-shared-VERSION.i386.rpm This package contains the shared libraries (libmysqlclient.so*) that certain languages and applications need to dynamically load and use MySQL.
• MySQL-shared-compat-VERSION.i386.rpm This package includes the shared libraries for both MySQL 3.23 and MySQL 4.0. Install this package instead of MySQL-shared, if you have applications installed that are dynamically linked against MySQL 3.23 but you want to upgrade to MySQL 4.0 without breaking the library dependencies. This package is available since MySQL 4.0.13.
• MySQL-embedded-VERSION.i386.rpm The embedded MySQL server library (from MySQL 4.0).
• MySQL-VERSION.src.rpm This contains the source code for all of the previous packages. It can also be used to rebuild the RPMs on other architectures (for example, Alpha or SPARC).

To see all files in an RPM package (for example, a MySQL-server RPM), run:

shell> rpm -qpl MySQL-server-VERSION.i386.rpm

To perform a standard minimal installation, run:

shell> rpm -i MySQL-server-VERSION.i386.rpm
shell> rpm -i MySQL-client-VERSION.i386.rpm

To install just the client package, run:

shell> rpm -i MySQL-client-VERSION.i386.rpm

RPM provides a feature to verify the integrity and authenticity of packages before installing them. If you would like to learn more about this feature please see section 2.1.4 Verifying Package Integrity Using MD5 Checksums or GnuPG.

The server RPM places data under the `/var/lib/mysql' directory. The RPM also creates the appropriate entries in `/etc/init.d/' to start the server automatically at boot time. (This means that if you have performed a previous installation and have made changes to its startup script, you may want to make a copy of the script so you don't lose it when you install a newer RPM.) See section 2.4.2.2 Starting and Stopping MySQL Automatically for more information on how MySQL can be started automatically on system startup.

If you want to install the MySQL RPM on older Linux distributions that do not support initialization scripts in `/etc/init.d' (directly or via a symlink), you should create a symbolic link that points to the location where your initialization scripts actually are installed. For example, if that location is `/etc/rc.d/init.d', use these commands before installing the RPM to create `/etc/init.d' as a symbolic link that points there:

shell> cd /etc; ln -s rc.d/init.d .

However, all current major Linux distributions should already support the new directory layout that uses `/etc/init.d', because it is required for LSB (Linux Standard Base) compliance.

If the RPM files that you install include MySQL-server, the mysqld server should be up and running after installation. You should now be able to start using MySQL. See section 2.4 Post-installation Setup and Testing.

If something goes wrong, you can find more information in the binary installation chapter. See section 2.2.5 Installing MySQL on Other Unix-like Systems.

2.2.3 Installing MySQL on Mac OS X

Beginning with MySQL 4.0.11, you can install MySQL on Mac OS X 10.2 (``Jaguar'') using a Mac OS X binary package in PKG format instead of the binary tarball distribution. Please note that older versions of Mac OS X (for example, 10.1.x) are not supported by this package.

The package is located inside a disk image (.dmg) file, that you first need to mount by double-clicking its icon in the Finder. It should then mount the image and display its contents.

Note: Before proceeding with the installation, be sure to shut down all running MySQL server instances by either using the MySQL Manager Application (on Mac OS X Server) or via mysqladmin shutdown on the command line.

To actually install the MySQL PKG file, double click on the package icon. This launches the Mac OS X Package Installer, which will guide you through the installation of MySQL.

Due to a bug in the Mac OS X package installer, you may sometimes see the error message You cannot install this software on this disk. (null) in the destination disk selection dialogue. If this error occurs, simply click the Go Back button once to return to the previous screen. Then click Continue to advance to the destination disk selection again, and you should be able to choose the destination disk correctly. We have reported this bug to Apple and they are investigating this problem.

The Mac OS X PKG of MySQL will install itself into `/usr/local/mysql-<version>' and will also install a symbolic link `/usr/local/mysql', pointing to the new location. If a directory named `/usr/local/mysql' already exists, it will be renamed to `/usr/local/mysql.bak' first. Additionally, it will install the grant tables in the mysql database by executing mysql_install_db after the installation.

The installation layout is similar to the one of the binary distribution; all MySQL binaries are located in the directory `/usr/local/mysql/bin'. The MySQL socket file is created as `/tmp/mysql.sock' by default. See section 2.1.8 Installation Layouts.

MySQL installation requires a Mac OS X user account named mysql (a user account with this name should exist by default on Mac OS X 10.2 and up).

If you are running Mac OS X Server, you already have a version of MySQL installed. The versions of MySQL that ship with Mac OS X Server versions are shown in the following table:

This manual section covers the installation of the official MySQL Mac OS X PKG only. Make sure to read Apple's help about installing MySQL (Run the ``Help View'' application, select ``Mac OS X Server'' help, and do a search for ``MySQL'' and read the item entitled ``Installing MySQL'').

For pre-installed versions of MySQL on Mac OS X Server, note especially that you should start mysqld with safe_mysqld instead of mysqld_safe if MySQL is older than version 4.0.

If you previously used Marc Liyanage's MySQL packages for Mac OS X from http://www.entropy.ch, you can simply follow the update instructions for packages using the binary installation layout as given on his pages.

If you are upgrading from Marc's 3.23.xx versions or from the Mac OS X Server version of MySQL to the official MySQL PKG, you also need to convert the existing MySQL privilege tables to the current format, because some new security privileges have been added. See section 2.5.8 Upgrading the Grant Tables.

If you would like to automatically start up MySQL during system startup, you also need to install the MySQL Startup Item. Starting with MySQL 4.0.15, it is part of the Mac OS X installation disk images as a separate installation package. Simply double-click the MySQLStartupItem.pkg icon and follow the instructions to install it.

Note that the Startup Item need be installed only once! There is no need to install it each time you upgrade the MySQL package later.

The Startup Item will be installed into `/Library/StartupItems/MySQL'. It adds a variable MYSQLCOM=-YES- to the system configuration file `/etc/hostconfig'. If you would like to disable the automatic startup of MySQL, simply change this variable to MYSQLCOM=-NO-.

On Mac OS X Server, the default MySQL installation uses the variable MYSQL in `/etc/hostconfig'. The MySQL AB Startup Item installer disables this variable by setting it to MYSQL=-NO-. This avoids boot time conflicts with the MYSQLCOM variable used by the MySQL AB Startup Item. However, it does not shut down an already running MySQL server.

After the installation, you can start up MySQL by running the following commands in a terminal window. Please note that you must have administrator privileges to perform this task.

If you have installed the Startup Item:

shell> sudo /Library/StartupItems/MySQL/MySQL start
(Enter your password, if necessary)
(Press Control-D or enter "exit" to exit the shell)

If you don't use the Startup Item, enter the following command sequence:

shell> cd /usr/local/mysql
shell> sudo ./bin/mysqld_safe
(Enter your password, if necessary)
(Press Control-Z)
shell> bg
(Press Control-D or enter "exit" to exit the shell)

You should now be able to connect to the MySQL server, for example, by running `/usr/local/mysql/bin/mysql'.

If you are installing MySQL for the first time, please remember to set a password for the MySQL root user!

This is done with the following two commands:

/usr/local/mysql/bin/mysqladmin -u root password "newpwd"
/usr/local/mysql/bin/mysqladmin -u root -h `hostname` password "newpwd"

Please make sure that the hostname command in the second line is enclosed by backtick characters (`), so the shell can replace it with the output of the command (which is the hostname of your system)!

You might want to also add aliases to your shell's resource file to access mysql and mysqladmin from the command line. The syntax for tcsh is:

alias mysql /usr/local/mysql/bin/mysql
alias mysqladmin /usr/local/mysql/bin/mysqladmin

For bash, use:

alias mysql=/usr/local/mysql/bin/mysql
alias mysqladmin=/usr/local/mysql/bin/mysqladmin

Even better, add /usr/local/mysql/bin to your PATH environment variable. For example, add the following line to your `$HOME/.tcshrc' file if your shell is tcsh:

setenv PATH ${PATH}:/usr/local/mysql/bin

If no `.tcshrc' file exists in your home directory, create it with a text editor.

If you are upgrading an existing installation, please note that installing a new MySQL PKG does not remove the directory of an older installation. Unfortunately, the Mac OS X Installer does not yet offer the functionality required to properly upgrade previously installed packages.

To use your existing databases with the new installation, you'll need to copy the contents of the old data directory to the new data directory. Make sure neither the old server nor the new one is running when you do this. After you have copied over the MySQL database files from the previous installation and have successfully started the new server, you should consider removing the old installation files to save disk space. Additionally, you should also remove older versions of the Package Receipt directories located in `/Library/Receipts/mysql-<version>.pkg'.

2.2.4 Installing MySQL on NetWare

Porting MySQL to NetWare was an effort spearheaded by Novell. Novell customers will be pleased to note that NetWare 6.5 will ship with bundled MySQL binaries, complete with an automatic commercial use license for all servers running that version of NetWare.

As of version 4.0.11, the MySQL server is available for Novell NetWare in binary package form. MySQL for NetWare is compiled using a combination of Metrowerks CodeWarrior for NetWare and special cross-compilation versions of the GNU autotools.

In order to host MySQL, the NetWare server must meet these requirements:

• NetWare version 6.5, or NetWare 6.0 with Support Pack 3 installed (You can obtain this at http://support.novell.com/filefinder/13659/index.html).
• The system must meet Novell's minimum requirements to run the respective version of NetWare.
• MySQL data, as well as the binaries themselves, must be installed on an NSS volume; traditional