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

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

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

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

MySQL AB offers two means of integrity checking: MD5 checksums and cryptographic signatures using GnuPG, the GNU Privacy Guard.

After you have downloaded the package, you should check, if the MD5 checksum matches the one provided on the MySQL download pages. Each package has an individual checksum, that you can verify with the following command:

shell md5sum package

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

Example:

shell md5sum mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz
155836a7ed8c93aee6728a827a6aa153
                mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz

You should check, if the resulting checksum matches the one printed on the download page right below the respective package.

Most mirror sites also offer a file named MD5SUMS, which also includes the MD5 checksums for all files included in the Downloads directory. Please note however that it's very easy to modify this file and it's not a very reliable method. If in doubt, you should consult different mirror sites and compare the results.

A more reliable method of verifying the integrity of a package is using cryptographic signatures. MySQL AB uses the GNU Privacy Guard (GnuPG), an Open Source alternative to the very well-known Pretty Good Privacy (PGP) by Phil Zimmermann. See http://www.gnupg.org/ and http://www.openpgp.org/ for more information about OpenPGP/GnuPG and how to obtain and install GnuPG on your system. Most Linux distributions already ship with GnuPG installed by default.

Beginning with MySQL 4.0.10 (February 2003), MySQL AB has started signing their downloadable packages with GnuPG. Cryptographic signatures are a much more reliable method of verifying the integrity and authenticity of a file.

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

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

Public Key (ASCII-armored):

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

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

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

After you have downloaded and imported the public build key, now download your desired MySQL package and the corresponding signature, which is also available from the download page. The signature has the file name extension .asc. For example, the signature for mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz would be mysql-standard-4.0.10-gamma-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 this file:

shell gpg --verify package.asc

Example:

shell gpg --verify mysql-standard-4.0.10-gamma-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.

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

shell rpm --checksig package.rpm

Example:

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

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

shell rpm --import pubkey

Example:

shell rpm --import mysql_pubkey.asc

In case you notice that the MD5 checksum or GPG signatures do not match, first try to download the respective package one more time, maybe from another mirror site. If you repeatedly can not 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 mailto:webmaster@@mysql.com or mailto:build@@mysql.com.

We use GNU Autoconf, so it is possible to port MySQL to all modern systems with working Posix threads and a C++ compiler. (To compile only the client code, a C++ compiler is required but not threads.) We use and develop the software ourselves primarily on Linux (SuSE and Red Hat), FreeBSD and Sun Solaris (Versions 8 and 9).

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

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

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

Please note that the preceding comparison is not to say that one OS is better or worse than the other in general. We are talking about choosing a particular OS for a dedicated purpose--running MySQL, and compare platforms in that regard only. With this in mind, the result of this comparison would be different if we included more issues into it. And in some cases, the reason one OS is better than the other could simply be that we have put forth more effort into testing on and optimising for that particular platform. We are just stating our observations to help you decide on which platform to use MySQL on in your setup.

The first decision to make is whether you want to use the latest development release or the last production (stable) release:

The second decision to make is whether you want to use a source distribution or a binary distribution. In most cases you should probably use a binary distribution, if one exists for your platform, as this generally will be easier to install than a source distribution.

In the following cases you probably will be better off with a source installation:

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

In the MySQL development process, multiple versions co-exist and are at a different stage. Naturally, relevant bugfixes from an earlier series also propagate upward.

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

Note that all releases have been tested at least with:

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

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

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

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

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

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

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

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

No one has to download a new release. The News section will tell you if the new release has something you really want. Appendix D, MySQL Change History .

We use the following policy when updating MySQL:

The current production release is Version 4.0; we have already moved active development to Version 4.1 and 5.0. Bugs will still be fixed in the 4.0 version, and critical bugs also in the 3.23 series. We don't believe in a complete freeze, as this also leaves out bug fixes and things that "must be done." "Somewhat frozen" means that we may add small things that "almost surely will not affect anything that's already working."

MySQL uses a slightly different naming scheme from most other products. In general it's relatively safe to use any version that has been out for a couple of weeks without being replaced with a new version. Section 2.2.6, “Which MySQL Version to Use ”.

We put a lot of time and effort into making our releases bug free. To our knowledge, we have not released a single MySQL version with any known 'fatal' repeatable bugs.

A fatal bug is something that crashes MySQL under normal usage, gives wrong answers for normal queries, or has a security problem.

We have documented all open problems, bugs and things that are dependent on design decisions. Section 1.7.6, “Known Errors and Design Deficiencies in MySQL ”.

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

Here is a description of how our build process works:

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

In addition to the binaries provided in platform-specific package formats (see Section 2.1, “Quick Standard Installation of MySQL ”), we do offer binary distributions for a number of platforms by means of compressed tar archives (.tar.gz).

These distributions are generated using the script Build-tools/Do-compile which compiles the source code and creates the binary tar.gz archive using scripts/make_binary_distribution These binaries are configured and built with the following compilers and options.

Binaries built on MySQL AB development systems:

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

The following compile options have been used for binary packages MySQL AB used to provide in the past. These binaries are no longer being updated, but the compile options are kept 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 s mailing list. Section 1.6.1.1, “The MySQL Mailing Lists ”.

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

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

For the Windows distribution, please see Section 2.1.1, “Installing MySQL on Windows ”.

This chapter covers the installation of MySQL binary distributions (.tar.gz Archives) for various platforms (see Section 2.2.10, “MySQL Binaries Compiled by MySQL AB ” for a detailed list).

In addition to these generic packages, we also offer binaries in platform-specific package formats for selected platforms. See Section 2.1, “Quick Standard Installation of MySQL ” for more information on how to install these.

The generic MySQL binary distributions are packaged as gzip-compressed GNU tar archives (.tar.gz). You need the following tools to install a MySQL binary distribution:

If you run into problems, please always use mysqlbug when posting questions to a MySQL mailing list. Even if the problem isn't a bug, mysqlbug gathers system information that will help others solve your problem. By not using mysqlbug, you lessen the likelihood of getting a solution to your problem. You will find mysqlbug in the bin directory after you unpack the distribution. Section 1.6.1.3, “How to Report Bugs or Problems ”.

The basic commands you must execute to install and use a MySQL binary distribution are:

shell groupadd mysql
shell useradd -g mysql mysql
shell cd /usr/local
shell gunzip  /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
shell ln -s full-path-to-mysql-VERSION-OS mysql
shell cd mysql
shell scripts/mysql_install_db
shell chown -R root  .
shell chown -R mysql data
shell chgrp -R mysql .
shell bin/mysqld_safe --user=mysql 
or
shell bin/mysqld_safe --user=mysql 
if you are running MySQL 4.x

You can add new users using the bin/mysql_setpermission script if you install the DBI and DBD-mysql Perl modules.

A more detailed description follows.

To install a binary distribution, follow these steps, then proceed to Section 2.4, “Post-installation Setup and Testing ”, for post-installation setup and testing:

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

You can start the MySQL server with the following command:

shell bin/mysqld_safe --user=mysql 

Now proceed to Section 4.7.2, “mysqld_safe, The Wrapper Around mysqld”, and Section 2.4, “Post-installation Setup and Testing ”.