This chapter describes how to obtain and install MySQL. A summary of the
procedure follows and later sections provide the details. If you plan to
upgrade an existing version of MySQL to a newer version rather than install
MySQL for the first time, see
Section 2.11, “Upgrading MySQL”, for information about upgrade
procedures and about issues that you should consider before upgrading.
Determine whether your platform is supported.
Please note that not all supported systems are equally suitable for
running MySQL. On some platforms it is much more robust and efficient
than others. See
Section 2.1.1, “Operating Systems Supported by MySQL”, for details.
Choose which distribution to install.
Several versions of MySQL are available, and most are available in
several 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”.
Perform any necessary post-installation
setup. After installing MySQL, read
Section 2.10, “Post-Installation Setup and Testing”. This section
contains important information about making sure the MySQL server is
working properly. It also describes how to secure the initial MySQL user
accounts, which have no passwords
until you assign passwords. The section applies whether you install
MySQL using a binary or source distribution.
Before installing MySQL, you should do the following:
Determine whether MySQL runs on your platform.
Choose a distribution to install.
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 support 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.
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 is only as stable as the
thread library it calls, even if everything else is perfect.
The capability of the kernel and the 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 CPU different from the original process.
The capability of the kernel and the thread library to run many
threads that acquire and release a mutex over a short critical
region frequently without excessive context switches. If the
implementation of
pthread_mutex_lock() is too anxious to
yield CPU time, this hurts MySQL tremendously. If this issue is not
taken care of, adding extra CPUs actually makes MySQL slower.
General filesystem stability and performance.
If your tables are large, performance is affected by 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 run MySQL successfully on the platform
in similar configurations. If this number is high, the likelihood of
encountering platform-specific surprises is much smaller.
Based on the preceding criteria, the best platforms for running MySQL at
this point are x86 with SuSE Linux using a 2.4 or 2.6 kernel, and
ReiserFS (or any similar Linux distribution) and SPARC with Solaris
(2.7-9). FreeBSD comes third, but we really hope it joins the top club
once the thread library is improved. We also hope that at some point we
are able to include into the top category all other platforms on which
MySQL currently compiles and runs, but not quite with the same level of
stability and performance. This requires some effort on our part in
cooperation with the developers of the operating systems 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, “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 might be
different if other factors were considered. In some cases, the reason
one OS is better for MySQL than another might simply be that we have
been able to put more effort into testing and optimizing for a
particular platform. We are just stating our observations to help you
decide which platform to use for running MySQL.
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.1 is the current development release series.
MySQL 5.0 is the current stable (production-quality) release
series. New releases are issued for bugfixes only; no new
features are being added that could effect stability.
MySQL 4.1 is the previous stable (production-quality) release
series. New releases are issued for critical bugfixes and
security fixes. No significant new features are to be added to
this series.
MySQL 4.0 and 3.23 are the old stable (production-quality) release
series. These versions are now retired, so new releases are
issued only to fix extremely critical bugs (primarily security
issues).
We do not believe in a complete code freeze because this prevents us
from making bugfixes and other fixes that must be done. By “somewhat
frozen” we mean that we may add small things that should not
affect anything that currently works in a production release.
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 5.0. 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 older system and want to upgrade, but do not
want to take the chance of having 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 only 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 are to be
based.
The MySQL naming scheme uses release names that consist of three
numbers and a suffix; for example,
mysql-4.1.2-alpha. The numbers within the
release name are 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 (2) 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 should be documented in the News section. See
Appendix D, 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 is tested before issuing a
release.
beta means that we are feature
complete and 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 critical bugs. A version changes from
alpha to beta when there have not 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.
All APIs, externally visible structures, and columns for SQL
statements will not change during future beta, release
candidate, or production releases.
rc is a release candidate; that is, a
beta that has been around a while and seems to work fine. Only
minor fixes are added. (A release candidate is what formerly was
known as a gamma 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 critical
repeatable bugs other than platform-specific bugs. Only critical
bugfixes are applied to the release. This is what we call a
production (stable) or “General Availability”
(GA) release.
MySQL uses a naming scheme that is slightly different from most other
products. In general, it is usually safe to use any version that has
been out for a couple of weeks without being replaced by a new
version within the same 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.
All releases have been tested at least with these tools:
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 19.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
determine whether the latest batch of optimizations actually
made the code faster. See
Section 7.1.4, “The MySQL Benchmark Suite”.
We also test the newest MySQL version in our internal production
environment, on at least one machine. We have more than 100GB 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 PKG
package installers for Mac OS X or Solaris. 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 is compiled with the core feature set. The
other (MySQL-Max) is compiled with an extended feature set. Both
versions are compiled from the same source distribution. All
native MySQL clients can connect to servers from either MySQL
version.
For RPM distributions, if you want to use the
MySQL-Max RPM, you must first install
the standard MySQL-server RPM.
Under some circumstances, you may be better off installing MySQL from
a source distribution:
You want to install MySQL at some explicit location. The standard
binary distributions are ready to run at any installation
location, but you might require even more flexibility to place
MySQL components where you want.
You want to configure mysqld
to ensure that features are available that might not be included
in the standard binary distributions. Here is a list of the most
common extra options that you may want to use to ensure feature
availability:
--with-innodb
--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 (such as
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 is committed to the source
repository and you can access it there. The bugfix does 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 contain more tests and examples than binary
distributions.
2.1.2.3. How and When Updates Are Released
MySQL is evolving quite rapidly and we want to share new developments
with other MySQL users. We try to produce a new release whenever we
have new and useful features that others also seem to have a need
for.
We also try to help users who request features that are easy to
implement. We take note of what our licensed users want, and we
especially take note of what our support customers want and try to
help them in this regard.
No one is required to download
a new release. The News section helps you determine whether the new
release has something you really want. See
Appendix D, MySQL Change History.
We use the following policy when updating MySQL:
Releases are issued within each 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. However, if small bugs are found, a release with only
bugfixes is issued.
Working releases/bugfixes 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 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 are included in the next release.
If by any chance a fatal bug is found in a release, our policy is
to fix it in 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. We
haven't 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.)
Our aim is to fix everything that is fixable without 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 of them.
Here is a description of our build process:
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 can never
recur without being detected. (About 90% of all fixed bugs have
test cases.)
We create test cases for each new feature that we add to MySQL.
Before we start to build a new MySQL release, we ensure that all
reported repeatable bugs for that MySQL version (3.23.x, 4.0.x,
4.1.x, 5.0.x, 5.1.x, and so on) are fixed. If something is
impossible to fix due to some internal design decision in MySQL,
we document this in the manual. See
Section A.8, “Known Issues in MySQL”.
We do a build on all platforms for which we support binaries and
run our test suite and benchmark suite on all of them.
We do not publish a binary for a platform for which the test or
benchmark suite fails. If the problem is due to a general error
in the source, we fix it and do the build plus tests on all
systems again from scratch.
The build and test process takes a week. 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://dev.mysql.com/, we send out an announcement message
to the mysql and
announce mailing lists. See
Section 1.7.1, “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 been needed for only a handful of
releases.
To quickly give our users access to the latest MySQL features, we
try to produce 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, despite our best efforts, we receive any bug reports after a
release is issued that a critical problem exists for the build
on a specific platform, we fix it at once and build a new
'a' release for that platform. Thanks to our large user
base, problems are found and resolved very quickly.
Our track record for making stable releases is quite good. In the
last 150 releases, we had to do a new build for fewer than 10 of
them. In three 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 of MySQL AB, we 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.
RPM distributions prior to MySQL 3.22 are user-contributed. Beginning
with MySQL 3.22, RPM distributions that we make available through
our Web site are generated by MySQL AB.
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.
Anyone who has more optimal options for any of the following
configure commands can mail them to the
MySQL internals mailing list. See
Section 1.7.1, “MySQL Mailing Lists”.
If you want to compile a debug version of MySQL, you should add
--with-debug or
--with-debug=full to the following
configure commands and
remove any
-fomit-frame-pointer options.
The following binaries are built on MySQL AB development systems:
Note that versions 8.1 and newer of the Intel compiler have
separate drivers for 'pure' C (icc)
and C++ (icpc); if you use
icc version 8.0 or
older for building MySQL, you will need to set
CXX=icc.
Linux 2.4.xx Intel Itanium 2 with
ecc
(Intel C++ Itanium Compiler 7.0):
The following binaries are built on third-party systems kindly
provided to MySQL AB by other users. These are provided only as a
courtesy; MySQL AB does not have full control over these systems, so
we can provide only limited support for the binaries built on them.
The following compile options have been used for binary packages that
MySQL AB provided in the past. These binaries no longer are being
updated, but the compile options are listed here for reference
purposes.
Check our downloads page at
http://dev.mysql.com/downloads/
for information about the current version of MySQL and for downloading
instructions. For a complete up-to-date list of MySQL download mirror
sites, see
http://dev.mysql.com/downloads/mirrors.html. You can also find
information there about becoming a MySQL mirror site and how to report a
bad or out-of-date mirror.
After you have downloaded the MySQL package that suits your needs and
before you attempt to install it, you should make sure that 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.
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.4.1. Verifying the MD5 Checksum
After you have downloaded a MySQL package, you should make sure that
its 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:
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.
Note: Make sure to verify
the checksum of the archive file
(for example, the .zip or
.tar.gz file) and not of the files that
are contained inside of the archive.
Note that not all operating systems support the
md5sum command. On some,
it is simply called md5,
and 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 use the command
openssl md5
package_name
instead. A Windows implementation of the
md5 command line utility is available from
http://www.fourmilab.ch/md5/.
winMd5Sum is a graphical
MD5 checking tool that can be obtained from
http://www.nullriver.com/index/products/winmd5sum.
2.1.4.2. 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 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, which you can
download from
http://www.keyserver.net/. The key that you want to obtain is
named
build@mysql.com. Alternatively, you can
cut and paste the key directly from the following text:
To import the build key into your personal public GPG keyring, use
gpg --import. For example, if you have saved the key
in a file named
mysql_pubkey.asc, the import command
looks like this:
shell> gpg --import mysql_pubkey.asc
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:
Distribution file
mysql-standard-4.0.17-pc-linux-i686.tar.gz
Signature file
mysql-standard-4.0.17-pc-linux-i686.tar.gz.asc
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. You can ignore any
insecure memory warning you might obtain.
See the GPG documentation for more information on how to work with
public keys.
2.1.4.3. Signature Checking Using RPM
For RPM packages, there is no separate signature. RPM packages 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
the MySQL public build key into your own GPG keyring, you need to
import the key into the RPM keyring first. RPM 4.1 no longer uses
your personal GPG keyring (or GPG itself). Rather, it maintains its
own keyring because it is 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, first obtain the key as described in
Section 2.1.4.2, “Signature Checking Using
GnuPG”. Then use
rpm --import to import
the key. For example, if you have saved the public key in a file
named
mysql_pubkey.asc, import it using this
command:
This section describes the default layout of the directories created by
installing binary or source distributions provided by MySQL AB. A
distribution provided by another vendor might use a layout different
from those shown here.
On Windows, the default installation directory is
C:\mysql. With MySQL version 4.1.5 and
higher, this has changed to C:\Program
Files\MySQL\MySQL Server 4.1, where 4.1 is the major version of
the installation. The folder has the following subdirectories:
Directory
Contents of Directory
bin
Client programs and the
mysqld server
data
Log files, databases
Docs
Documentation
examples
Example programs and scripts
include
Include (header) files
lib
Libraries
scripts
Utility scripts
share
Error message files
Installations created from MySQL AB's Linux RPM distributions result in
files under the following system directories:
Directory
Contents of Directory
/usr/bin
Client programs and scripts
/usr/sbin
The
mysqld server
/var/lib/mysql
Log files, databases
/usr/share/doc/packages
Documentation
/usr/include/mysql
Include (header) files
/usr/lib/mysql
Libraries
/usr/share/mysql
Error message and character
set files
/usr/share/sql-bench
Benchmarks
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:
Directory
Contents of Directory
bin
Client programs and the
mysqld server
data
Log files, databases
docs
Documentation, ChangeLog
include
Include (header) files
lib
Libraries
scripts
mysql_install_db
share/mysql
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
include/mysql
Include (header) files
info
Documentation in Info format
lib/mysql
Libraries
libexec
The
mysqld server
share/mysql
Error message files
sql-bench
Benchmarks and
crash-me test
var
Databases and log files
Within its 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
The next several sections cover 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.8, “Installing MySQL on Other Unix-Like Systems”, for
generic installation instructions for these packages that apply to all
platforms.
A native Windows distribution of MySQL has been available from MySQL AB
since version 3.21 and represents a sizable percentage of the daily
downloads of MySQL. This section describes the process for installing
MySQL on Windows.
With the release of MySQL 4.1.5, MySQL AB has introduced a new installer
for the Windows version of MySQL, combined with a new GUI Configuration
Wizard. This combination automatically installs MySQL, creates an option
file, starts the server, and secures the default user accounts.
Note: If you are upgrading
MySQL from an existing installation older than MySQL 4.1.5, you must
first perform the the procedure described in
Section 2.3.14, “Upgrading MySQL on Windows”.
To run MySQL on Windows, you need the following:
A 32-bit Windows operating system such as 9x, Me, NT, 2000, XP, or
Windows Server 2003.
A Windows NT-based operating system (NT, 2000, XP, 2003) permits you
to run the MySQL server as a service. The use of a Windows NT-based
operating system is strongly recommended. See
Section 2.3.11, “Starting MySQL as a Windows Service”.
Generally, you should install MySQL on Windows using an account that
has administrator rights. Otherwise, you may encounter problems with
certain operations such as editing the
PATH environment variable or accessing
the
Service Control Manager.
TCP/IP protocol support.
Enough space on the hard drive to unpack, install, and create the
databases in accordance with your requirements (generally a minimum
of 200 megabytes is recommended.)
There may also be other requirements, depending on how you plan to use
MySQL:
If you plan to connect to the MySQL server via ODBC, you need a
Connector/ODBC driver. See
Chapter 18, Connectors.
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 13.1.5, “CREATE TABLE Syntax”.
MySQL for Windows is available in several distribution formats:
Binary distributions are available that contain a setup program that
installs everything you need so that you can start the server
immediately. Another binary distribution format contains an archive
that you simply unpack in the installation location and then
configure yourself. For details, see
Section 2.3.1, “Choosing An Installation Package”.
The source distribution contains all the code and support files for
building the executables using the Visual Studio 7.1 compiler
system.
Generally speaking, you should use a binary distribution that includes an
installer. It is simpler to use than the others, and you need no
additional tools to get MySQL up and running. The installer for the
Windows version of MySQL, combined with a GUI Configuration Wizard,
automatically installs MySQL, creates an option file, starts the server,
and secures the default user accounts.
Starting with MySQL version 4.1.5, there are three install packages to
choose from when installing MySQL on Windows. The Packages are as
follows:
The Essentials Package:
This package has a filename similar to
mysql-essential-4.1.13a-win32.msi and
contains the minimum set of files needed to install MySQL on
Windows, including the Configuration Wizard. This package does not
include optional components such as the embedded server and
benchmark suite.
The Complete Package:
This package has a filename similar to
mysql-4.1.13a-win32.zip and contains
all files needed for a complete Windows installation, including the
Configuration Wizard. This package includes optional components such
as the embedded server and benchmark suite.
The Noinstall Archive:
This package has a filename similar to
mysql-noinstall-4.1.13a-win32.zip and
contains all the files found in the Complete install package, with
the exception of the Configuration Wizard. This package does not
include an automated installer, and must be manually installed and
configured.
The Essentials package is recommended for most users. It is provided as
an .msi file for use with the Windows
Installer. The Complete and Noinstall distributions are packaged as Zip
archives. To use them, you must have a tool that can unpack
.zip files.
2.3.2. Installing MySQL with the Automated Installer
Starting with MySQL 4.1.5, users can use the new MySQL Installation
Wizard and MySQL Configuration Wizard to install MySQL on Windows. The
MySQL Installation Wizard and MySQL Configuration Wizard are designed to
install and configure MySQL in such a way that new users can immediately
get started using MySQL.
The MySQL Installation Wizard and MySQL Configuration Wizard are
available in the Essentials and Complete install packages. They are
recommended for most standard MySQL installations. Exceptions include
users who need to install multiple instances of MySQL on a single server
host and advanced users who want complete control of server
configuration.
MySQL Installation Wizard is an installer for the MySQL server that
uses the latest installer technologies for Microsoft Windows. The
MySQL Installation Wizard, in combination with the MySQL
Configuration Wizard, allows a user to install and configure a MySQL
server that is ready for use immediately after installation.
The MySQL Installation Wizard is the standard installer for all MySQL
server distributions, version 4.1.5 and higher. Users of previous
versions of MySQL need to shut down and remove their existing MySQL
installations manually before installing MySQL with the MySQL
Installation Wizard. See
Section 2.3.3.7, “Upgrading MySQL with the Installation Wizard”,
for more information on upgrading from a previous version.
Microsoft has included an improved version of their Microsoft Windows
Installer (MSI) in the recent versions of Windows. MSI has become
the de-facto standard for application installations on Windows 2000,
Windows XP, and Windows Server 2003. The MySQL Installation Wizard
makes use of this technology to provide a smoother and more flexible
installation process.
The Microsoft Windows Installer Engine was updated with the release of
Windows XP; those using a previous version of Windows can reference
this Microsoft Knowledge Base article for information on
upgrading to the latest version of the Windows Installer Engine.
In addition, Microsoft has introduced the WiX (Windows Installer XML)
toolkit recently. This is the first highly acknowledged Open Source
project from Microsoft. We have switched to WiX because it is an
Open Source project and it allows us to handle the complete Windows
installation process in a flexible manner using scripts.
Improving the MySQL Installation Wizard depends on the support and
feedback of users like you. If you find that the MySQL Installation
Wizard is lacking some feature important to you, or if you discover
a bug, please report it in our bugs database using the instructions
given in
Section 1.8, “How to Report Bugs or Problems”.
2.3.3.2. Downloading and Starting the MySQL Installation Wizard
The MySQL installation packages can be downloaded from
http://dev.mysql.com/downloads/. If the package you download is
contained within a Zip archive, you need to extract the archive
first.
The process for starting the wizard depends on the contents of the
installation package you download. If there is a
setup.exe file present, double-click it
to start the installation process. If there is an
.msi file present, double-click it to
start the installation process.
2.3.3.3. Choosing an Install Type
There are three installation types available:
Typical,
Complete, and
Custom.
The Typical installation
type installs the MySQL server, the
mysql
command-line client, and the command-line utilities. The command-line
clients and utilities include
mysqldump,
myisamchk, and several other tools to help you
manage the MySQL server.
The Complete installation
type installs all components included in the installation package.
The full installation package includes components such as the
embedded server library, the benchmark suite, support scripts, and
documentation.
The Custom installation
type gives you complete control over which packages you wish to
install and the installation path that is used. See
Section 2.3.3.4, “The Custom Install Dialog”, for more
information on performing a custom install.
If you choose the Typical
or
Complete installation types
and click the Next button, you
advance to the confirmation screen to verify your choices and begin
the installation. If you choose the
Custom installation type
and click the Next button, you
advance to the custom installation dialog, described in
Section 2.3.3.4, “The Custom Install Dialog”.
2.3.3.4. The Custom Install Dialog
If you wish to change the installation path or the specific components
that are installed by the MySQL Installation Wizard, choose the
Custom
installation type.
A tree view on the left side of the custom install dialog lists all
available components. Components that are not installed have a red
X icon; components that are installed have a gray icon. To
change whether a component is installed, click on that component's
icon and choose a new option from the drop-down list that appears.
You can change the default installation path by clicking the
Change... button to the right of the
displayed installation path.
After choosing your installation components and installation path,
click the Next button to advance to
the confirmation dialog.
2.3.3.5. The Confirmation Dialog
Once you choose an installation type and optionally choose your
installation components, you advance to the confirmation dialog.
Your installation type and installation path are displayed for you
to review.
To install MySQL if you are satisfied with your settings, click the
Install button. To change your settings, click the
Back button. To exit the MySQL Installation Wizard without
installing MySQL, click the Cancel
button.
After installation is complete, you have the option of registering
with the MySQL web site. Registration gives you access to post in
the MySQL forums at
forums.mysql.com,
along with the ability to report bugs at
bugs.mysql.com and
to subscribe to our newsletter. The final screen of the installer
provides a summary of the installation and gives you the option to
launch the MySQL Configuration Wizard, which you can use to create a
configuration file, install the MySQL service, and configure
security settings.
2.3.3.6. Changes Made by MySQL Installation Wizard
Once you click the Install button, the
MySQL Installation Wizard begins the installation process and makes
certain changes to your system which are described in the sections
that follow.
Changes to the Registry
The MySQL Installation Wizard creates one Windows registry key in a
typical install situation, located in
HKEY_LOCAL_MACHINE\SOFTWARE\MySQL AB.
The MySQL Installation Wizard creates a key named after the major
version of the server that is being installed, such as
MySQL Server 4.1. It contains two string
values, Location and
Version. The
Location
string contains the path to the installation directory. In a default
installation it contains C:\Program
Files\MySQL\MySQL Server 4.1\. The
Version string contains the release
number. For example, for an installation of MySQL Server 4.1.5, the
key contains a value of 4.1.5.
These registry keys are used to help external tools identify the
installed location of the MySQL server, preventing a complete scan
of the hard-disk to determine the installation path of the MySQL
server. The registry keys are not required to run the server, and if
you install MySQL using the
noinstall Zip archive, the registry keys
are not created.
Changes to the Start Menu
The MySQL Installation Wizard creates a new entry in the Windows
Start menu under a common MySQL menu heading named after the
major version of MySQL that you have installed. For example, if you
install MySQL 4.1, the MySQL Installation Wizard creates a MySQL
Server 4.1 section in the start menu.
The following entries are created within the new
Start menu section:
MySQL Command Line Client: This
is a shortcut to the mysql
command-line client and is configured to connect as the
root user. The shortcut prompts for a
root user password when you connect.
MySQL Server Instance Config Wizard:
This is a shortcut to the MySQL Configuration Wizard. Use this
shortcut to configure a newly installed server, or to
reconfigure an existing server.
MySQL Documentation: This is a
link to the MySQL server documentation that is stored locally in
the MySQL server installation directory. This option is not
available when the MySQL server is installed from the Essentials
installation package.
Changes to the File System
The MySQL Installation Wizard by default installs the MySQL server to
C:\Program Files\MySQL\MySQL
Server
4.1, where
Program Files is the default
location for applications in your system, and
4.1 is the major version of
your MySQL server. This is the new location for the MySQL server,
replacing the former default location of
c:\mysql.
By default, all MySQL applications are stored in a common directory at
C:\Program Files\MySQL,
where
Program Files is the default
location for applications in your Windows installation. A typical
MySQL installation on a developer machine might look like this:
This approach makes it easier to manage and maintain all MySQL
applications installed on a particular system.
2.3.3.7. Upgrading MySQL with the Installation Wizard
From MySQL version 4.1.5, the new MySQL Installation Wizard can
perform server upgrades automatically using the upgrade capabilities
of MSI. That means you do not need to remove a previous installation
manually before installing a new release. The installer
automatically shuts down and removes the previous MySQL service
before installing the new version.
Automatic upgrades are available only when upgrading between
installations that have the same major and minor version numbers.
For example, you can upgrade automatically from MySQL 4.1.5 to MySQL
4.1.6, but not from MySQL 4.1 to MySQL 5.0.
If you are upgrading MySQL version 4.1.4 or
earlier to version 4.1.5 or later, you must first manually shut down
and remove the older installation before upgrading. Be sure to back
up your databases before performing such an upgrade, so that you can
restore the databases after the upgrade is completed.
It is always recommended that you back up your data before
performing any upgrades.
The MySQL Configuration Wizard helps automate the process of
configuring your server under Windows. The MySQL Configuration
Wizard creates a custom my.ini file by
asking you a series of questions and then applying your responses to
a template to generate a
my.ini file that is tuned to your
installation.
The MySQL Configuration Wizard is included with the MySQL server
starting with MySQL version 4.1.5, but is designed to work with
MySQL servers versions 4.1 and higher. The MySQL Configuration
Wizard is currently available for Windows users only.
The MySQL Configuration Wizard is to a large extent the result of
feedback that MySQL AB has received from many users over a period of
several years. However, if you find that it lacks some feature
important to you, please report it in our bugs database using the
instructions given in
Section 1.8, “How to Report Bugs or Problems”.
2.3.4.2. Starting the MySQL Configuration Wizard
The MySQL Configuration Wizard is typically launched from the MySQL
Installation Wizard, as the MySQL Installation Wizard exits. You can
also launch the MySQL Configuration Wizard by clicking the
MySQL Server Instance Config Wizard entry in the
MySQL section of the Windows
Start menu.
Alternatively, you can navigate to the
bin directory of your MySQL installation
and launch the MySQLInstanceConfig.exe
file directly.
2.3.4.3. Choosing a Maintenance Option
If the MySQL Configuration Wizard detects an existing
my.ini file, you have the option of
either reconfiguring your existing server, or removing the server
instance by deleting the my.ini