The recommended way to install MySQL on RPM-based Linux
distributions is by using the RPM packages. The RPMs that we
provide to the community should work on all versions of Linux that
support RPM packages and use
glibc 2.3. To
obtain RPM packages, see Section 2.1.3, “How to Get MySQL”.
For non-RPM Linux distributions, you can install MySQL using a
.tar.gz package. See
Section 2.2, “Installing MySQL on Unix/Linux Using Generic Binaries”.
Installations created from our Linux RPM distributions result in files under the system directories shown in the following table.
Table 2.16. MySQL Installation Layout for Linux RPM Packages
|Directory||Contents of Directory|
|Client programs and scripts|
|The mysqld server|
|Log files, databases|
|Manual in Info format|
|Unix manual pages|
|Include (header) files|
|Miscellaneous support files, including error messages, character set files, sample configuration files, SQL for database installation|
RPM distributions of MySQL are also provided by other vendors. Be aware that they may differ from those built by us in features, capabilities, and conventions (including communication setup), and that the instructions in this manual do not necessarily apply to installing them. The vendor's instructions should be consulted instead. Because of these differences, RPM packages built by us check whether such RPMs built by other vendors are installed. If so, the RPM does not install and produces a message explaining this.
Conflicts can arise when an RPM from another vendor is already
installed, such as when a vendor's convention about which files
belong with the server and which belong with the client library
differ from the breakdown used for Oracle packages. In such
cases, attempts to install an Oracle RPM with rpm
-i may result in messages that files in the RPM to be
installed conflict with files from an installed package (denoted
mysql-libs in the following paragraphs).
We provide a
MySQL-shared-compat package with
each MySQL release. This package is meant to replace
mysql-libs and provides a
replacement-compatible client library for older MySQL series.
MySQL-shared-compat is set up to make
mysql-libs obsolete, but
rpm explicitly refuses to replace obsoleted
packages when invoked with
-U), which is why installation with
rpm -i produces a conflict.
MySQL-shared-compat can safely be installed
mysql-libs because libraries are
installed to different locations. Therefore, it is possible to
install shared-compat first, then manually remove
mysql-libs before continuing with the
installation. After mysql-libs is removed, the dynamic linker
stops looking for the client library in the location where
mysql-libs puts it, and the library provided
MySQL-shared-compat package takes
Another alternative is to install packages using
yum. In a directory containing all RPM
packages for a MySQL release, yum install
MySQL*rpm installs them in the correct order and
mysql-libs in one step without
In most cases, you need to install only the
MySQL-client packages to get a functional MySQL
installation. The other packages are not required for a standard
RPMs for MySQL Cluster.
Beginning with MySQL 5.1.24, standard MySQL server RPMs built by
MySQL no longer provide support for the
NDBCLUSTER storage engine. MySQL
Cluster users should check the MySQL Cluster Downloads page at
http://dev.mysql.com/downloads/cluster/ for RPMs that should
work with most Linux distributions for both of these release
When upgrading a MySQL Cluster RPM installation, you must
upgrade all installed RPMs, including the
For more information about installing MySQL Cluster from RPMs, see Section 18.104.22.168, “Installing MySQL Cluster from RPM”.
For upgrades, if your installation was originally produced by installing multiple RPM packages, it is best to upgrade all the packages, not just some. For example, if you previously installed the server and client RPMs, do not upgrade just the server RPM.
The RPM packages shown in the following list are available. The
names shown here use a suffix of
.glibc23.i386.rpm, but particular packages
can have different suffixes, described later.
The MySQL server. You need this unless you only want to connect to a MySQL server running on another machine.
The standard MySQL client programs. You probably always want to install this package.
The libraries and include files that are needed if to compile other MySQL clients, such as the Perl modules. Install this RPM if you intend to compile C API applications.
This package contains debugging information. It is specific to
Red Hat Enterprise Linux.
are never needed to use MySQL software; this is true both for
the server and for client programs. However, they contain
additional information that might be needed by a debugger to
analyze a crash.
This package contains the shared libraries
libmysqlclient.so*) that certain languages
and applications need to dynamically load and use MySQL. It
contains single-threaded and thread-safe libraries. Install
this RPM if you intend to compile or run C API applications
that depend on the shared client library. If you install this
package, do not install the
This package includes the shared libraries for older releases,
up to the current release. It contains single-threaded and
thread-safe libraries. Install this package instead of
MySQL-shared if you have applications
installed that are dynamically linked against older versions
of MySQL but you want to upgrade to the current version
without breaking the library dependencies.
These are like the
package, but are for the “MySQL Enterprise Server
– Advanced Edition” products. Install these
packages rather than the normal
MySQL-shared-compat package if you want to
included shared client libraries for older MySQL versions.
The embedded MySQL server library.
Packages that contain additional files for MySQL Cluster installations.
MySQL-ndb-tools RPM requires a
working installation of perl. Prior to MySQL 5.1.18, the
packages were also required. See
Section 2.15, “Perl Installation Notes”, and
Section 17.4.23, “ndb_size.pl — NDBCLUSTER Size Requirement Estimator”, for
This package includes the MySQL test suite.
This contains the source code for all of the previous packages. It can also be used to rebuild the RPMs on other architectures (for example, Alpha or SPARC).
The suffix of RPM package names (following the
VERSION value) has the following
CPU values indicate the type of system
for which the package is built.
PLATFORM indicates the platform and
CPU indicates the processor type or
All packages are dynamically linked against
glibc 2.3. The
PLATFORM value indicates whether the
package is platform independent or intended for a specific
platform, as shown in the following table.
Table 2.17. MySQL Linux Installation Packages
|Platform independent, should run on any Linux distribution that supports
|Red Hat Enterprise Linux 4 or 5|
|SuSE Linux Enterprise Server 10 or 11|
In MySQL 5.1, only
packages are available currently.
CPU value indicates the processor
type or family for which the package is built.
Table 2.18. MySQL Installation Packages for Linux CPU Identifiers
|Intended Processor Type or Family|
|Pentium processor or better, 32 bit|
|64-bit x86 processor|
|Itanium (IA-64) processor|
To see all files in an RPM package (for example, a
MySQL-server RPM), run a command like this:
rpm -qpl MySQL-server-
To perform a standard minimal installation, install the server and client RPMs:
rpm -i MySQL-server-shell>
rpm -i MySQL-client-
To install only the client programs, install just the client RPM:
rpm -i MySQL-client-
RPM provides a feature to verify the integrity and authenticity of
packages before installing them. To learn more about this feature,
see Section 2.1.4, “Verifying Package Integrity Using MD5 Checksums or
The server RPM places data under the
/var/lib/mysql directory. The RPM also
creates a login account for a user named
(if one does not exist) to use for running the MySQL server, and
creates the appropriate entries in
/etc/init.d/ to start the server
automatically at boot time. (This means that if you have performed
a previous installation and have made changes to its startup
script, you may want to make a copy of the script so that you do
not lose it when you install a newer RPM.) See
Section 22.214.171.124, “Starting and Stopping MySQL Automatically”, for more information on how
MySQL can be started automatically on system startup.
In MySQL 5.1.49 and later, during an upgrade installation using the RPM packages, if the MySQL server is running when the upgrade occurs, the MySQL server is stopped, the upgrade occurs, and the MySQL server is restarted. If the MySQL server is not already running when the RPM upgrade occurs, the MySQL server is not started at the end of the installation.
If something goes wrong, you can find more information in the binary installation section. See Section 2.2, “Installing MySQL on Unix/Linux Using Generic Binaries”.
The accounts that are listed in the MySQL grant tables initially have no passwords. After starting the server, you should set up passwords for them using the instructions in Section 2.12, “Postinstallation Setup and Testing”.
During RPM installation, a user named
a group named
mysql are created on the system.
This is done using the useradd,
groupadd, and usermod
commands. Those commands require appropriate administrative
privileges, which is required for locally managed users and groups
(as listed in the
/etc/group files) by the RPM installation
process being run by
If you log in as the
mysql user, you may find
that MySQL displays “Invalid (old?) table or database
name” errors that mention
similar files created by MySQL or operating system utilities. You
can safely ignore these error messages or remove the files or
directories that cause them if you do not need them.
For nonlocal user management (LDAP, NIS, and so forth), the administrative tools may require additional authentication (such as a password), and will fail if the installing user does not provide this authentication. Even if they fail, the RPM installation will not abort but succeed, and this is intentional. If they failed, some of the intended transfer of ownership may be missing, and it is recommended that the system administrator then manually ensures some appropriate user and group exists and manually transfers ownership following the actions in the RPM spec file.