This chapter describes how to obtain and install MySQL:
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.
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”.
Note: 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.10, “Upgrading MySQL” for information about upgrade
procedures and about issues that you should consider before
upgrading.
Perform any necessary post-installation
setup. After installing MySQL, read
Section 2.9, “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 or not 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 different CPU than 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 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 the
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 using a 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
joins the top club once the thread library is improved. We also
hope that at some point we is 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 requires 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. In some cases, the reason one OS is better than the
other could 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.0 is the newest development release series and is
under very active development for new features. Alpha
releases have been issued to allow more widespread
testing.
MySQL 4.1 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 4.0 is the previous 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 do not believe in a complete freeze, as this also leaves
out bugfixes and things that “must be done.”
“Somewhat frozen” means that we may add small
things that “almost surely do not affect anything that's
currently 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.1. 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 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 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 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 API's, extern visible structures and columns for SQL
commands 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 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.
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 20.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”.
Another test is that we use 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 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 servers from either MySQL
version.
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 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 included 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 up)
--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 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 support
customers want and try to help them out.
No one has to download a new release. The News section tells
you if 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 will be included in the next release.
If by any chance a fatal bug is found in a release, we
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. 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 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 of them.
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 can never recur without being detected. (About 90% of
all fixed bugs have a test case.)
We 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, and so forth) 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 (15+ platforms) 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 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://dev.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 been needed for only 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, despite our best efforts, we get any bug reports after
the release is done that there was something critically
wrong with 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 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 releases. 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.
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.
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.
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 3.22 are user-contributed.
Beginning with MySQL 3.22, RPM distributions are generated by
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.
2.1.3. How to Get MySQL
Check the MySQL downloads page
(http://dev.mysql.com/downloads/) for information about the
current version and for downloading instructions. For a complete
up-to-date list of MySQL download mirror sites, see
http://dev.mysql.com/downloads/mirrors.html. There you can
also find information 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 also
use the command openssl md5 package_name
instead. A DOS/Windows implementation of the
md5 command line utility is available from
http://www.fourmilab.ch/md5/. A graphical MD5
checking tool is winMd5Sum, which 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. You can
download the key 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:
You can import the build key into your personal public GPG
keyring by using gpg --import. For example,
if you save the key in a file named
mysql_pubkey.asc, the import command
looks like this:
shell> gpg --import mysql_pubkey.asc
See the GPG documentation for more information 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:
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 the insecure
memory warning.
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 the previous section.
Then use rpm --import to import the key.
For example, if you have the public key stored 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. If you install a distribution provided by another
vendor, some other layout might be used.
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 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 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
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.7, “Installing MySQL on Other Unix-Like Systems” for generic
installation instructions for these packages that apply to all
platforms.
A native Windows version 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.
If you have installed a version of MySQL prior to version 4.1.5,
you must perform the following steps:
Obtain and install the distribution.
Set up an option file if necessary.
Select the server that you want to use.
Start the server.
Assign passwords to the initial MySQL accounts.
This process also must be followed with newer MySQL installations
where the installation package does not include an installer.
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 Visual Studio
2003 compiler system.
Generally speaking, you should use the binary distribution. It is
simpler, and you need no additional tools to get MySQL up and
running.
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.12, “Starting MySQL as a Windows Service”.
Note: If you download the distribution via FTP, we recommend
the use of an adequate FTP client with a resume feature to
avoid corruption of files during the download process.
A tool that can read .zip files, to
unpack the distribution file.
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.)
You may also have the following optional requirements:
If you need tables with a size larger than 4GB, install
MySQL on an NTFS or newer filesystem. Do not forget to use
MAX_ROWS and
AVG_ROW_LENGTH when you create tables.
See Section 13.1.5, “CREATE TABLE Syntax”.
2.3.2. Choosing An Installation Package
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.
2.3.3. 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, and
are recommended for most standard MySQL installations.
Exceptions include users who need to install multiple instances
of MySQL on a single server and advanced users who want complete
control of server configuration.
MySQL Installation Wizard is a new 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 manually shut down
and remove their existing MySQL installations before
installing MySQL with the MySQL Installation Wizard. See
Section 2.3.4.7, “Upgrading MySQL” 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.
Using the 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 progress.
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.
Further, Microsoft has introduced the WiX (Windows Installer
XML) tool set recently. It is the first highly acknowledged
Open Source project from Microsoft. We switched to WiX because
it is an Open Source project and it allows us to handle the
complete Windows installation process in a flexible way with
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 use our
MySQL Bug System to
request features or report problems.
2.3.4.2. Downloading and Starting the MySQL Installation Wizard
The MySQL server install 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 install package you download. If there is a
setup.exe file present, double-click it to
start the install process. If there is a
.msi file present, double-click it to start
the install process.
2.3.4.3. Choosing an Install Type
There are up 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.4.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 confirm
your choices and begin the installation. If you choose the
Custom installation type and click the Next
button, you advance to the custom install dialog, described in
Section 2.3.4.4, “The Custom Install Dialog”
2.3.4.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, you should choose the Custom
installation type.
All available components are listed in a tree view on the left
side of the custom install dialog. 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 the
component's icon and choose an 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 install components and installation path,
click the Next button to advance to the confirmation dialog.
2.3.4.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 are given 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 the 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.
2.3.4.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 when 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 connecting.
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
re-configure 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
essential 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 recommended location for the
MySQL server, replacing the previous 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 may look
like this:
This approach makes it easier to manage and maintain all MySQL
applications installed on a particular system.
2.3.4.7. Upgrading MySQL
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 only available 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.
