High Performance MySQL [Electronic resources] نسخه متنی

1.1 Binary Versus Compiled-From-Source Installations

There are two ways you can install MySQL.
As a novice administrator, you may have simply installed a binary
package that had precompiled executables, libraries, and
configuration files, and placed those files wherever the maker of the
binary package decided they should go.

It's exceedingly rare for a Windows user to compile his own copy of MySQL. If you're running MySQL on Windows, feel free to download your copy from the MySQL web site and skip this discussion.

Alternatively, for any number of reasons, you might have decided to
compile the MySQL binaries on your own, by downloading a source
tarball and configuring the installation to best meet your needs.
However, don't do so lightly. Compiling from source
has led to countless hours of pain for some users, mostly due to
subtle bugs in their compilers or thread libraries. For this very
reason, the standard binaries provided by MySQL AB are statically
linked. That means they are immune to any bugs in your locally
installed libraries.

There aren't too many places where the issue of
"binary versus
compiled-from-source" will come into play in the
average MySQL tuning regimen, but they do happen. For example, in
Chapter 10, our advice on chrooting your
installation can be used only if every file MySQL needs is brought
into a single directory tree, which might not be the case in a binary
installation.

For a novice administrator on a simple installation, we recommend
using a binary package (such as an RPM) to set up your system.
However, once you progress to the point of really needing to tinker
with the "guts" of MySQL, you will
probably want to quickly go back, change a
configure flag, and recompile.

1.1.1 MySQL.com Binary Versus Distribution Binary

One
thing to keep in mind is that there
are a number of sources for binary packages, and nearly all of them
set up the system differently.

For example, you can download the binary installation from the
MySQL.com web site. You can also nstall the binary distribution
included by your
Linux distribution vendor, or the
one you grabbed from the
FreeBSD ports
collection. Finally, you can downloaded a binary for a platform that
isn't officially supported, but on which someone is
keeping a MySQL version current, such as the Amiga
architecture.^[1] In any of these
cases, you will end up with different directory layouts, compilation
options, etc.

^[1] At the time that sentence was written,
it was entirely theoretical: the thinking was
"I'm not aware of anything, but
surely someone will do that!"
In researching it, we found that MySQL for Amiga was, indeed,
happening. For those who read German, there's an
article from Amiga Magazine at http://www.amiga-magazin.de/magazin/a08-01/mysql/
that describes how to do it, and a mailing list at http://groups.yahoo.com/group/Amiga_MySql/
for people working on it as well.

If you use the binary distributions from
anyone other than MySQL AB, your support options may be significantly
decreased, simply by virtue of having limited yourself to seeking
help from those who use that particular distribution. Even a question
as simple as, "Where is the
my.cnf file located on the FreeBSD port of
MySQL?" is going to limit those who can respond to
two groups: those who have run MySQL using the FreeBSD port, and
those on the mailing list or newsgroup, etc. who have encountered
that question before. On the plus side, if your distribution has
automated security announcements and updates, you probably never need
to worry about patching MySQL if a security flaw is discovered.

Many binary distributors of MySQL mold it to fit
"their" layout. For example, the
Debian distribution places the config files in
/etc/mysql/, some language-specific files in
/usr/share/mysql/, the executables directly into
/usr/bin/, etc. It's not
"the Debian way" to segregate an
application's binaries; it incorporates them into
the system as a whole. Likewise, in those places it does incorporate
them, it does so in what may seem like an odd manner. For instance,
you might expect config files to go directly into
/etc/, but instead they get put in
/etc/mysql/. It can be confusing if
you're trying to find everything you need to modify,
or if you're trying to later convert from one type
of installation to the other.

The MySQL.com-supplied tarball binary packages, however, behave more
like the source-compilation process. All the
filesconfiguration files, libraries, executables, and the
database files themselvesend up in a single directory tree,
created specifically for the MySQL install. This is typically
/usr/local/mysql, but it can be altered as
needed at installation time. Because this behavior is much the same
as a source-compiled installation, the available support from the
MySQL community is much greater. It also makes things easier if you
decide later to instead use a MySQL installation you compile from
source.

On the other hand, the MySQL-supplied binary packages that are
distributed using package-management formats such as RPM are laid out
similarly to the format of the system they are designed for. For
example, the RPM installation you get from MySQL.com will have its
files laid out similarly to the Red Hat-supplied RPM. This is so
because it's not uncommon for a Linux distribution
to ship an RPM that hasn't been thoroughly tested
and is broken in fairly serious ways. The RPM files MySQL.com
distributes are intended as upgrade paths for users with such a
problem so they can have "just what they have now,
but it works."

Because of that, if you're going to install a binary
you download from MySQL.com, we highly recommend using the tarball
formatted files. They will yield the familiar directory structure the
average MySQL administrator is used to seeing.