General Installation Issues
===========================
How to Get MySQL
----------------
Check the MySQL homepage (`http://www.mysql.com/') for information
about the current version and for downloading instructions.
Our main mirror is located at `http://mirrors.sunsite.dk/mysql/'.
a
bad or out-of-date mirror.
Verifying Package Integrity Using `MD5 Checksums' or `GnuPG'
------------------------------------------------------------
After you have downloaded the MySQL package that suits your needs and
before you attempt to install it, you should make sure it is intact and
has not been tampered with.
MySQL AB offers two means of integrity checking: `MD5 checksums' and
cryptographic signatures using `GnuPG', the `GNU Privacy Guard'.
Verifying the `MD5 Checksum'
----------------------------
following command:
shell> md5sum
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 '
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.
Signature Checking Using `GnuPG'
--------------------------------
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.
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 . 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)
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
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.
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 .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) "
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 .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
Example:
shell> rpm --import mysql_pubkey.asc
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 or .
Operating Systems Supported by MySQL
------------------------------------
We use GNU Autoconf, so it is possible to port MySQL to all modern
systems with working Posix threads and a C++ compiler. (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).
* AIX 4.x, 5.x with native threads. *Note IBM-AIX::.
* Amiga.
* BSDI 2.x with the MIT-pthreads package. *Note BSDI::.
* BSDI 3.0, 3.1 and 4.x with native threads. *Note BSDI::.
* SCO OpenServer with a recent port of the FSU Pthreads package.
*Note SCO::.
* SCO UnixWare 7.1.x. *Note SCO UnixWare::.
* DEC Unix 4.x with native threads. *Note Alpha-DEC-UNIX::.
* FreeBSD 2.x with the MIT-pthreads package. *Note FreeBSD::.
* FreeBSD 3.x and 4.x with native threads. *Note FreeBSD::.
* FreeBSD 4.x with Linuxthreads. *Note FreeBSD::.
* HP-UX 10.20 with the DCE threads or the MIT-pthreads package.
*Note HP-UX 10.20::.
* HP-UX 11.x with the native threads. *Note HP-UX 11.x::.
* Linux 2.0+ with LinuxThreads 0.7.1+ or `glibc' 2.0.7+. *Note
Linux::.
* Mac OS X. *Note Mac OS X::.
* NetBSD 1.3/1.4 Intel and NetBSD 1.3 Alpha (Requires GNU make).
*Note NetBSD::.
* Novell NetWare 6.0. *Note Novell NetWare::.
* OpenBSD > 2.5 with native threads. OpenBSD < 2.5 with the
MIT-pthreads package. *Note OpenBSD::.
* OS/2 Warp 3, FixPack 29 and OS/2 Warp 4, FixPack 4. *Note OS/2::.
* SGI Irix 6.x with native threads. *Note SGI-Irix::.
* Solaris 2.5 and above with native threads on SPARC and x86. *Note
Solaris::.
* SunOS 4.x with the MIT-pthreads package. *Note Solaris::.
* Tru64 Unix
* Windows 9x, Me, NT, 2000 and XP. *Note Windows::.
* General stability of the thread library. A platform may have
excellent reputation otherwise, but if the thread library is
unstable in the code that is called by MySQL, even if everything
else is perfect, MySQL will be only as stable as the thread
library.
to run on
a different CPU than the original process.
* The ability of the kernel and/or the thread library to run many
threads which acquire/release a mutex over a short critical region
frequently without excessive context switches. In other words, if
the implementation of `pthread_mutex_lock()' is too anxious to
yield CPU time, this will hurt MySQL tremendously. If this issue
is not taken care of, adding extra CPUs will actually make MySQL
slower.
* General filesystem stability/performance.
* Ability of the filesystem to deal with large files at all and deal
with them efficiently, if your tables are big.
* Our level of expertise here at MySQL AB with the platform. If we
know a platform well, we introduce platform-specific
optimisations/fixes enabled at compile time. We can also provide
advice on configuring your system optimally for MySQL.
* The amount of testing of similar configurations we have done
internally.
* The number of users that have successfully run MySQL on that
platform in similar configurations. If this number is high, the
chances of hitting some platform-specific surprises are much
smaller.
Based on the preceding criteria, the best platforms for running MySQL
at this point are x86 with SuSE Linux 8.2, 2.4 kernel, and ReiserFS (or
any similar Linux distribution) and SPARC with Solaris (2.7-9). FreeBSD
comes third, but we really hope it will join the top club once the
thread library is improved. We also hope that at some point we will be
able to include 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. *Note Mailing-list::.
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.
Which MySQL Version to Use
--------------------------
The first decision to make is whether you want to use the latest
development release or the last production (stable) release:
* Normally, if you are beginning to use MySQL for the first time or
trying to port it to some system for which there is no binary
distribution, we recommend going with the production release
(currently version 4.0). Note that all MySQL releases are checked
with the MySQL benchmarks and an extensive test suite before each
release (even the development releases).
* Otherwise, if you are running an old system and want to upgrade,
but don't want to take chances with a non-seamless upgrade, you
should upgrade to the latest in the same branch you are using
(where only the last version number is newer than yours). We have
tried to fix only fatal bugs and make small, relatively safe
changes to that version.
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:
* If 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 get even more flexibility).
configured with the most important extended options like
transaction-safe tables. Both versions are compiled from the same
source distribution. All native `MySQL' clients can connect to
both MySQL versions.
The extended MySQL binary distribution is marked with the `-max'
suffix and is configured with the same options as `mysqld-max'.
*Note `mysqld-max': mysqld-max.
If you want to use the `MySQL-Max' RPM, you must first install the
standard `MySQL-server' RPM.
* `--with-innodb' (default for MySQL 4.0 and onwards)
* `--with-berkeley-db' (not available on all platforms)
* `--with-raid'
* `--with-libwrap'
* `--with-named-z-libs' (This is done for some of the binaries)
* `--with-debug[=full]'
* The default binary distribution is normally compiled with support
for all character sets and should work on a variety of processors
from the same processor family.
optimised for your processor.
* If you want to read (and/or modify) the C and C++ code that makes
up MySQL, you should get a source distribution. The source code is
always the ultimate manual. Source distributions also contain more
tests and examples than binary distributions.
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:
* 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.
* The third number (`0') is the version number within the release
level. This is incremented for each new distribution. Usually you
want the latest version for the release level you have chosen.
* The suffix (`alpha') indicates the stability level of the release.
The possible suffixes are:
- `alpha' indicates that the release contains some large
section of new code that hasn't been 100% tested. Known bugs
(usually there are none) should be documented in the News
section. *Note News::. There are also new commands and
extensions in most alpha releases. Active development that
may involve major code changes can occur on an alpha release,
but everything will be tested before doing a release. There
should be no known bugs in any MySQL release.
- `beta' means that all new code has been tested. No major new
features that could cause corruption on old code are added.
There should be no known bugs. A version changes from alpha
to beta when there haven't been any reported fatal bugs
within an alpha version for at least a month and we don't
plan to add any features that could make any old command more
unreliable.
- `gamma' is a beta that has been around a while and seems to
work fine. Only minor fixes are added. This is what many
other companies call a release.
- If there is no suffix, it means that the version has been run
for a while at many different sites with no reports of bugs
other than platform-specific bugs. Only critical bug fixes
are applied to the release. This is what we call a production
(stable) release.
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.
* For the old stable/production series `3.23', new versions are only
released for critical bugs.
* The current series `4.0') is stable/production quality, with new
versions released for bugfixes. No new features are added that
could influence the code stability.
* In the alpha branch `4.1' major new features are added. Sources
and binaries are available for use and testing on development
systems.
* The development branch `5.0' is only available from the BitKeeper
tree.
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:
An internal test suite
This is part of a production system for a customer. It has many
tables with hundreds of megabytes of data.
The MySQL benchmark suite
This runs a range of common queries. It is also a test to see
whether the latest batch of optimisations actually made the code
faster. *Note MySQL Benchmarks::.
The `crash-me' test
This tries to determine what features the database supports and
what its capabilities and limitations are. *Note MySQL
Benchmarks::.
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.
Installation Layouts
--------------------
This section describes the default layout of the directories created by
installing binary and source distributions.
A binary distribution is installed by unpacking it at the installation
location you choose (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 `/usr/local/bin' directory
rather than in `/usr/local/mysql/scripts'.
* 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 script `scripts/make_binary_distribution'.
How and When Updates Are Released
---------------------------------
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. *Note News::.
We use the following policy when updating MySQL:
* 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.
* Production (stable-tested) releases are meant to appear about 1-2
times a year, but if small bugs are found, a release with only bug
fixes will be released.
* Working releases/bug fixes to old releases are meant to appear
about every 1-8 weeks.
* Binary distributions for some platforms will be made by us for
major releases. Other people may make binary distributions for
other systems but probably less frequently.
* We usually make patches available as soon as we have located and
fixed small bugs. They usually are immediately available from our
public BitKeeper repositories. They will also be included in the
next release.
* Non-critical but annoying bugs will be added to the MySQL source
repository and they will be fixed in the next release.
* If there is, by any chance, a fatal bug in a release we will make
a new release as soon as possible. We would like other companies
to do this, too.
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. *Note
Which version::.
Release Philosophy - No Known Bugs in Releases
----------------------------------------------
We put a lot of time and effort into making our releases bug free. To
our knowledge, we have not released a single MySQL version with any
_known_ 'fatal' repeatable bugs.
A fatal bug is something that crashes MySQL under normal usage, 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. *Note Bugs::.
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:
* We monitor bugs from our customer support list, the MySQL external
mailing lists and the bugs database at `http://bugs.mysql.com/'.
* 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 of it and
include this into our test system to ensure that the bug will never
come back. (About 90% of all fixed bugs have a test case.)
* We also create test cases for all new features we add to MySQL.
* Before we start to build a new MySQL release, we ensure that all
reported repeatable bugs for the MySQL version (3.23.x, 4.0.x, etc)
are fixed. If something is impossible to fix (because some
internal design decision in MySQL) we document this in the manual.
*Note Bugs::.
* We do a build on all platforms for which we support binaries (15+
platforms) and run our test suite and benchmark suite on all of
them.
* We will not publish a binary for a platform for which the test or
benchmark suite fails. If it's a general error in the source, we
fix this and do the build plus tests on all systems again, from
scratch.
* If we, during the build and test process (which takes 2-3 days),
receive a report regarding a fatal bug (for example, one that
causes a core dump), we fix this and restart the build process.
* After publishing the binaries on `http://www.mysql.com/', we send
out an announce email on the `mysql' and `announce' mailing lists.
*Note Mailing-list::. The announcement message contains a list of
all changes to the release and any known problems with the release.
(The 'known problems' section in the release notes has only been
needed in a handful of releases.)
* To quickly give our users access to the latest MySQL features, we
do a new MySQL release every 4-5 weeks.
* If we, after the release is done, get any bug reports that there
was (after all) anything critically wrong with the build on a
specific platform, we will fix this at once and build a new `'a''
release for that platform. Thanks to our large user base, problems
are found quickly.
* Our track record for making good releases is quite good. In the
last 150 releases, we had to do a new build for less than 10
releases (in 3 of these cases, the bug was a faulty glibc library
on one of our build machines that took us a long time to track
down).
MySQL Binaries Compiled by MySQL AB
-----------------------------------
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.
tar
archives (`.tar.gz').
are configured and built with the following compilers and
options.
Binaries built on MySQL AB development systems:
--enable-thread-safe-client --enable-local-infile
--enable-assembler --disable-shared
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static'
Linux 2.4.xx Intel Itanium 2 with `ecc' (Intel C++ Itanium Compiler 7.0)
`CC=ecc CFLAGS="-O2 -tpp2 -ip -nolib_inline" CXX=ecc CXXFLAGS="-O2
-tpp2 -ip -nolib_inline" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile'
Linux 2.4.xx Intel Itanium with `ecc' (Intel C++ Itanium Compiler 7.0)
`CC=ecc CFLAGS=-tpp1 CXX=ecc CXXFLAGS=-tpp1 ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile'
Linux 2.4.xx alpha with `ccc' (Compaq C V6.2-505 / Compaq C++ V6.3-006)
`CC=ccc CFLAGS="-fast -arch generic" CXX=cxx CXXFLAGS="-fast -arch
generic -noexceptions -nortti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-mysqld-ldflags=-non_shared
--with-client-ldflags=-non_shared --disable-shared'
--enable-local-infile --disable-shared
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static'
Sun Solaris 8 x86 with `gcc' 3.2.3
`CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3
-fno-omit-frame-pointer -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared --with-innodb'
Sun Solaris 8 sparc with `gcc' 3.2
`CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3
-fno-omit-frame-pointer -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler --with-named-z-libs=no
--with-named-curses-libs=-lcurses --disable-shared'
Sun Solaris 8 sparc 64bit with `gcc' 3.2
`CC=gcc CFLAGS="-O3 -m64 -fno-omit-frame-pointer" CXX=gcc
CXXFLAGS="-O3 -m64 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler --with-named-z-libs=no
--with-named-curses-libs=-lcurses --disable-shared'
--prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--with-named-curses-libs=-lcurses --disable-shared'
Sun Solaris 9 sparc with `cc-5.0' (Sun Forte 5.0)
`CC=cc-5.0 CXX=CC ASFLAGS="-xarch=v9" CFLAGS="-Xa -xstrconst -mt
-D_FORTEC_ -xarch=v9" CXXFLAGS="-noex -mt -D_FORTEC_ -xarch=v9"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler --with-named-z-libs=no
--enable-thread-safe-client --disable-shared'
IBM AIX 4.3.2 ppc with `gcc' 3.2.3
`CFLAGS="-O2 -mcpu=powerpc -Wa,-many " CXX=gcc CXXFLAGS="-O2
-mcpu=powerpc -Wa,-many -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no --disable-shared'
IBM AIX 4.3.3 ppc with `xlC_r' (IBM Visual Age C/C++ 6.0)
`CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192"
CXX=xlC_r CXXFLAGS ="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192"
./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --disable-shared --with-innodb'
IBM AIX 5.1.0 ppc with `gcc' 3.3
`CFLAGS="-O2 -mcpu=powerpc -Wa,-many" CXX=gcc CXXFLAGS="-O2
-mcpu=powerpc -Wa,-many -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --with-server-suffix="-pro"
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --disable-shared'
HP-UX 10.20 pa-risc1.1 with `gcc' 3.1
`CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC" CXX=gcc
CXXFLAGS="-DHPUX -I/opt/dce /include -felide-constructors
-fno-exceptions -fno-rtti -O3 -fPIC" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile --with-pthread
--with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC
--disable-shared'
HP-UX 11.11 pa-risc2.0 64bit with `aCC' (HP ANSI C++ B3910B A.03.33)
`CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64 ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile --disable-shared'
HP-UX 11.11 pa-risc2.0 32bit with `aCC' (HP ANSI C++ B3910B A.03.33)
`CC=cc CXX=aCC CFLAGS="+DAportable" CXXFLAGS="+DAportable"
./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared --with-innodb'
Apple Mac OS X 10.2 powerpc with `gcc' 3.1
`CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3
-fno-omit-frame-pointer -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared'
FreeBSD 4.7 i386 with `gcc' 2.95.4
`CFLAGS=-DHAVE_BROKEN_REALPATH ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-z-libs=not-used --disable-shared'
QNX Neutrino 6.2.1 i386 with `gcc' 2.95.3qnx-nto 20010315
`CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3
-fno-omit-frame-pointer -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared'
The following binaries are built on third-party systems kindly provided
to MySQL AB by other users. Please note that these are only provided as
a courtesy. Since MySQL AB does not have full control over these
systems, we can only provide limited support for the binaries built on
these systems.
SCO Unix 3.2v5.0.6 i386 with `gcc' 2.95.3
`CFLAGS="-O3 -mpentium" LDFLAGS=-static CXX=gcc CXXFLAGS="-O3
-mpentium -felide-constructors" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared'
SCO OpenUnix 8.0.0 i386 with `CC' 3.2
`CC=cc CFLAGS="-O" CXX=CC ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--enable-thread-safe-client --disable-shared'
Compaq Tru64 OSF/1 V5.1 732 alpha with `cc/cxx' (Compaq C V6.3-029i / DIGITAL C++ V6.1-027)
`CC="cc -pthread" CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline
speed -speculate all" CXX="cxx -pthread" CXXFLAGS="-O4 -ansi_alias
-fast -inline speed -speculate all -noexceptions -nortti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-prefix=/usr/local/mysql
--with-named-thread-libs="-lpthread -lmach -lexc -lc"
--disable-shared --with-mysqld-ldflags=-all-static'
SGI Irix 6.5 IP32 with `gcc' 3.0.1
`CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXXFLAGS="-O3
-fno-omit-frame-pointer -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared'
FreeBSD 5.0 sparc64 with `gcc' 3.2.1
`CFLAGS=-DHAVE_BROKEN_REALPATH ./configure
--prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile --disable-shared
--with-innodb'
The following compile options have been used for binary packages MySQL
AB used to provide in the past. These binaries are no longer being
updated, but the compile options are kept here for reference purposes.
Linux 2.2.xx sparc with `egcs' 1.1.2
`CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3
-fno-omit-frame-pointer -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler --disable-shared'
Linux 2.2.x with x686 with `gcc' 2.95.2
`CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro
-felide-constructors -fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --enable-assembler
--with-mysqld-ldflags=-all-static --disable-shared
--with-extra-charsets=complex'
SunOS 4.1.4 2 sun4c with `gcc' 2.7.2.1
`CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors" ./configure
--prefix=/usr/local/mysql --disable-shared
--with-extra-charsets=complex --enable-assembler'
SunOS 5.5.1 (and above) sun4u with `egcs' 1.0.3a or 2.90.27 or gcc 2.95.2 and newer
`CC=gcc CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors
-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql
--with-low-memory --with-extra-charsets=complex --enable-assembler'
SunOS 5.6 i86pc with `gcc' 2.8.1
`CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
--with-low-memory --with-extra-charsets=complex'
BSDI BSD/OS 3.1 i386 with `gcc' 2.7.2.1
`CC=gcc CXX=gcc CXXFLAGS=-O ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex'
BSDI BSD/OS 2.1 i386 with `gcc' 2.7.2
`CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex'
AIX 2 4 with `gcc' 2.7.2.2
`CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex'
Anyone who has more optimal options for any of the preceding
configurations listed can always mail them to the MySQL internals s
mailing list. *Note Mailing-list::.
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 *Note Windows installation::.
Installing a MySQL Binary Distribution
--------------------------------------
This chapter covers the installation of MySQL binary distributions
(`.tar.gz' Archives) for various platforms (see *Note MySQL binaries::
for a detailed list).
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:
* GNU `gunzip' to uncompress the distribution.
problems
(with long file names, for example). In that case, you should
install GNU `tar' first.
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. *Note Bug reports::.
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 &
If your version of MySQL is older than 4.0, substitute `bin/safe_mysqld'
for `bin/mysqld_safe' in the final command.
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
*Note Post-installation::, for post-installation setup and testing:
1. Pick the directory under which you want to unpack the
distribution, and move into it. In the following example, we
unpack the distribution under `/usr/local' (The following
instructions, therefore, assume you have permission to create
files and directories in `/usr/local'. If that directory is
protected, you will need to perform the installation as `root'.)
2. Obtain a distribution file from one of the sites listed in *Note
Getting MySQL: Getting MySQL.
MySQL binary distributions are provided as compressed `tar'
archives and have names like `mysql-VERSION-OS.tar.gz', where
`VERSION' is a number (for example, `3.21.15'), and `OS' indicates
the type of operating system for which the distribution is intended
(for example, `pc-linux-gnu-i586'). Note that all binaries are
built from the same MySQL source distribution.
3. Add a user and group for `mysqld' to run as:
shell> groupadd mysql
shell> useradd -g mysql mysql
These commands add the `mysql' group and the `mysql' user. The
syntax for `useradd' and `groupadd' may differ slightly on
different versions of Unix. They may also be called `adduser' and
`addgroup'. You may wish to call the user and group something
else instead of `mysql'.
4. Change into the intended installation directory:
shell> cd /usr/local
5. Unpack the distribution, which will create the installation
directory. Then create a symbolic link to that directory:
shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
shell> ln -s full-path-to-mysql-VERSION-OS mysql
Using GNU tar, you can also replace the first line with the
following alternative command to decompress and extract the
distribution in one go:
shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
`/usr/local/mysql'.
6. Change into the installation directory:
shell> cd mysql
You will find several files and subdirectories in the `mysql'
directory. The most important for installation purposes are the
`bin' and `scripts' subdirectories.
`bin'
This directory contains client programs and the server You
should add the full pathname of this directory to your `PATH'
environment variable so that your shell finds the MySQL
programs properly. *Note Environment variables::.
`scripts'
This directory contains the `mysql_install_db' script used to
initialise the `mysql' database containing the grant tables
that store the server access permissions.
7. If you would like to use `mysqlaccess' and have the MySQL
distribution in some non-standard place, you must change the
location where `mysqlaccess' expects to find the `mysql' client.
Edit the `bin/mysqlaccess' script at approximately line 18.
Search for a line that looks like this:
$MYSQL = '/usr/local/bin/mysql'; # path to mysql executable
Change the path to reflect the location where `mysql' actually is
stored on your system. If you do not do this, you will get a
`Broken pipe' error when you run `mysqlaccess'.
8. Create the MySQL grant tables (necessary only if you haven't
installed MySQL before):
shell> scripts/mysql_install_db
Note that MySQL versions older than Version 3.22.10 started the
MySQL server when you run `mysql_install_db'. This is no longer
true.
9. Change ownership of binaries to `root' and ownership of the data
directory to the user that you will run `mysqld' as:
shell> chown -R root /usr/local/mysql/.
shell> chown -R mysql /usr/local/mysql/data
shell> chgrp -R mysql /usr/local/mysql/.
the
`group' attribute to the `mysql' group.
10. If you want to install support for the Perl `DBI'/`DBD' interface,
see *Note Perl support::.
More information can be
found in the `support-/files/mysql/003/mysql.server' script itself and in
*Note Automatic start::.
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 *Note `mysqld_safe': mysqld_safe, and *Note
Post-installation::.
[Назад] [Содержание] [Вперед]
| Главная |