Windows での MySQL のインストールは、以下のステップになります。

Windows 用 MySQL は、以下の2種類の形式で提供されます。

一般的には、バイナリディストリビューションを使用することをお勧めします。このディストリビューションの方が単純で、MySQL のセットアップと実行に追加のツールを必要としないからです。

C:\> echo %WINDIR%

[mysqld]
# set basedir to your installation path
basedir=D:/mysql
# set datadir to the location of your data directory
datadir=D:/mydata/data

shell> mysqld --console

InnoDB: The first specified datafile c:\ibdata\ibdata1 did not exist:
InnoDB: a new database to be created!
InnoDB: Setting file c:\ibdata\ibdata1 size to 209715200
InnoDB: Database physically writes the file full: wait...
InnoDB: Log file c:\iblogs\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file c:\iblogs\ib_logfile0 size to 31457280
InnoDB: Log file c:\iblogs\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file c:\iblogs\ib_logfile1 size to 31457280
InnoDB: Log file c:\iblogs\ib_logfile2 did not exist: new to be created
InnoDB: Setting log file c:\iblogs\ib_logfile2 size to 31457280
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: creating foreign key constraint system tables
InnoDB: foreign key constraint system tables created
011024 10:58:25  InnoDB: Started

mysqld: ready for connections
Version: '4.0.14-log'  socket: ''  port: 3306

shell> C:\mysql\bin\mysqld

shell> C:\mysql\bin\mysqladmin -u root shutdown

shell> C:\mysql\bin\mysqladmin -u root shutdown

shell> mysqld --install

shell> C:\mysql\bin\mysqld --install

shell> C:\mysql\bin\mysqld --install mysql --defaults-file=C:\my-opts.cnf

shell> C:\mysql\bin\mysqld --install-manual

shell> mysqld --remove

C:\> C:\mysql\bin\mysqlshow
C:\> C:\mysql\bin\mysqlshow -u root mysql
C:\> C:\mysql\bin\mysqladmin version status proc
C:\> C:\mysql\bin\mysql test

C:\> C:\mysql\bin\mysql mysql
mysql> DELETE FROM user WHERE Host='localhost' AND User='';
mysql> FLUSH PRIVILEGES;
mysql> QUIT
C:\> C:\mysql\bin\mysqladmin -u root password your_password

C:\> mysqladmin --user=root --password=your_password shutdown

Linux に MySQL をインストールする場合は、RPM パッケージを使用することをお勧めします。MySQL RPM は、現在、SuSE Linux 7.3 システム上でビルドされていますが、rpm をサポートし glibc を使用するほとんどのバージョンの Linux 上で動作します。

RPM ファイルに関する問題が発生した場合（たとえば、``Sorry, the host 'xxxx' could not be looked up'' というエラーが表示された場合）は、項2.6.2.1. 「Linux の注意事項 （バイナリディストリビューション）」 を参照してください。

ほとんどの場合、MySQL-server パッケージと MySQL-client パッケージをインストールするだけで済みます。最小インストールの場合は、その他のパッケージは必要ありません。 追加機能を備えた MySQL Max サーバを実行したい場合は、MySQL-server RPM をインストールした後に MySQL-Max RPM をインストールしてください。 See 項4.8.5. 「mysqld-max（拡張 mysqld サーバ）」。

MySQL 4.0 パッケージのインストール中に依存関係エラーが発生した場合（たとえば、``error: removing these packages would break dependencies: libmysqlclient.so.10 is needed by ...''）、MySQL-shared-compat パッケージもインストールする必要があります。このパッケージには、下位互換性のために両方の共有ライブラリ（MySQL 4.0 の libmysqlclient.so.12 と MySQL 3.23 の libmysqlclient.so.10）が含まれています。

多くの Linux ディストリビューションにはまだ MySQL 3.23 が同梱されており、アプリケーションを動的にリンクしてディスク領域を節約しています。これらの共有ライブラリが別個のパッケージ（MySQL-shared など）に含まれている場合は、このパッケージをインストールして、MySQL サーバおよびクライアントのパッケージをアップグレードするだけで十分です（これらのパッケージは静的にリンクされ共有ライブラリに依存しません）。MySQL サーバと同じパッケージに共有ライブラリが含まれているディストリビューションの場合（Red Hat Linux など）は、バージョン 3.23 の MySQL-shared RPM をインストールするか、MySQL-shared-compat パッケージを使用します。

以下の RPM パッケージが用意されています。

RPM パッケージ（MySQL-server RPM など）内のすべてのファイルを確認するには、以下のコマンドを実行します。

shell> rpm -qpl MySQL-server-VERSION.i386.rpm

最小インストールを行うには、以下のコマンドを実行します。

shell> rpm -i MySQL-server-VERSION.i386.rpm MySQL-client-VERSION.i386.rpm

クライアントパッケージだけをインストールするには、以下のコマンドを実行します。

shell> rpm -i MySQL-client-VERSION.i386.rpm

RPM には、パッケージをインストールする前にその完全性と信頼性を検証する機能が備えられています。この機能の詳細については、項2.2.2. 「MD5 チェックサムまたは GnuPG によるパッケージ完全性の検証」 を参照してください。

サーバ RPM は、/var/lib/mysql ディレクトリの下にデータを配置します。また、ブート時にサーバを自動的に起動するための適切なエントリを /etc/init.d/ に作成します（したがって、旧バージョンのインストールを実行しており、起動スクリプトに変更を加えている場合、新しいバージョンの RPM のインストール時にそのスクリプトが失われないようにするためにはスクリプトのコピーを作成する必要があります）。システム起動時に MySQL が自動的に起動されるようにする方法については、項2.4.3. 「MySQL を自動的に起動および停止する」 を参照してください。

/etc/init.d の初期化スクリプトをサポートしていない旧バージョンの Linux ディストリビューションに MySQL RPM をインストールする（直接または symlink を使用して）場合は、初期化スクリプトが実際にインストールされる場所を指すシンボリックリンクを作成してください。たとえば、その場所が /etc/rc.d/init.d である場合、RPM をインストールする前に以下のコマンドを使用して、その場所を指すシンボリックリンクとして /etc/init.d を作成します。

shell> cd /etc; ln -s rc.d/init.d .

ただし、/etc/init.d を使用するこの新しいディレクトリレイアウトは、LSB（Linux Standard Base）に準拠するために必要であるので、最新のすべての主要 Linux ディストリビューションではすでにサポートされています。

インストールする RPM ファイルに MySQL-server が含まれている場合は、インストール後に mysqld デーモンが起動します。 これで、MySQL の使用を開始できるようになりました。 See 項2.4. 「インストール後の設定とテスト」。

何か問題があった場合は、バイナリインストールの章を参照してください。 See 項2.2.9. 「MySQL バイナリディストリビューションのインストール」。

MySQL 4.0.11 からは、バイナリ tarball ディストリビューションではなく Mac OS X PKG バイナリパッケージを使用して、Mac OS X 10.2（``Jaguar''）に MySQL をインストールできるようになりました。注意: このパッケージは、これより古いバージョンの Mac OS X（10.1.x など）はサポートしていません。

パッケージは、ディスクイメージ（.dmg）ファイル内にあります。まず、ファインダ内でこのファイルのアイコンをダブルクリックしてマウントする必要があります。ディスクイメージファイルをマウントすると、イメージがマウントされその内容が表示されます。

注意: インストールを続行する前に、MySQL Manager Application（Mac OS X Server 上で）を使用するかコマンドラインで mysqladmin shutdown を使用して、稼動しているすべての MySQL サーバインスタンスを必ずシャットダウンしてください。

MySQL PKG を実際にインストールするには、パッケージのアイコンをダブルクリックします。これにより、Mac OS Package Installer が起動されます。このインストーラの指示に従って MySQL のインストールを行います。

MySQL の Mac OS X PKG は、自身を /usr/local/mysql-<version> にインストールします。また、新しい場所を指すシンボリックリンク /usr/local/mysql もインストールします。/usr/local/mysql という名前のディレクトリがすでに存在する場合は、まずそのディレクトリの名前を /usr/local/mysql.bak に変更します。さらに、インストール後に mysql_install_db を実行して、mysql データベースに権限テーブルをインストールします。

インストールレイアウトは、バイナリディストリビューションのインストールレイアウトと類似しています。つまり、すべての MySQL バイナリが /usr/local/mysql/bin ディレクトリに配置されます。 MySQL ソケットファイルは、デフォルトで /tmp/mysql.sock として作成されます。 See 項2.2.5. 「インストールレイアウト」。

MySQL インストールには、mysql という名前の Mac OS X ユーザアカウントが必要です（Mac OS X 10.2 以降の場合、この名前を持つユーザアカウントがデフォルトで存在します）。

Mac OS X Server を実行している場合、MySQL はすでにインストールされています。

ここでは、公式の MySQL Mac OS X PKG のインストールについてのみ説明します。必ず、MySQL のインストールに関する Apple のヘルプを参照してください（``Help View'' アプリケーションを実行して、``Mac OS X Server'' ヘルプを選択し、``MySQL'' を検索して、``Installing MySQL'' という項目を参照してください）。

特に、Mac OS X Server 上のプリインストール版の MySQL は、mysqld_safe コマンドではなく safe_mysqld コマンドで起動することに注意してください。

http://www.entropy.ch から入手した Marc Liyanage の Mac OS X 用 MySQL パッケージを使用している場合は、同氏のページに示されているバイナリインストールレイアウトによるパッケージの更新手順説明に従うだけで済みます。

Marc の 3.23.xx バージョンまたは Mac OS X Server バージョンの MySQL から公式の MySQL PKG にアップグレードする場合は、いくつかの新しいセキュリティ特権が追加されているので、既存の MySQL 特権テーブルを現在の形式に変換する必要もあります。 See 項2.5.6. 「権限テーブルのアップグレード」。

また、システムのブートアップ時に MySQL を自動的に起動する場合は、MySQL Startup Item をインストールする必要があります。MySQL 4.0.15 からは、MySQL Startup Item は Mac OS X インストールディスクイメージの一部として別個のインストールパッケージとなっています。MySQLStartupItem.pkg アイコンをダブルクリックし、指示に従ってインストールします。

注意: このインストールは 1 回だけ行います。MySQL パッケージをアップグレードするたびに Startup Item をインストールする必要はありません。

Mac OS X パッケージインストーラにバグがあるため、インストール先ディスク選択画面に You cannot install this software on this disk. (null) というエラーメッセージが表示されることがあります。このエラーが発生した場合は、Go Back ボタンをクリックして前の画面に戻ります。次に、Continue をクリックして、もう一度インストール先ディスク選択画面に進み、適切なインストール先ディスクを選択することができます。この問題は、Apple に報告済みで、現在同社で調査中です。

Startup Item は、/Library/StartupItems/MySQL にインストールされます。 これによって、システム設定ファイル /etc/hostconfig に変数 MYSQLCOM=-YES- が追加されます。MySQL の自動起動を無効にする場合は、この変数を MYSQLCOM=-NO- に変更します。

Mac OS X Server では、Startup Item インストールスクリプトが自動的に /etc/hostconfig の変数 MYSQL を MYSQL=-NO- に変更して、デフォルト MySQL インストールの起動を無効にします。これは、ブートアップ時のコンフリクトを回避するために行われます。ただし、すでに稼動している MySQL サーバがシャットダウンされることはありません。

インストール後は、ターミナルウィンドウで以下のコマンドを実行して MySQL を起動することができます。この作業を行うには管理者特権が必要であることに注意してください。

Startup Item をインストールした場合は、以下のコマンドを入力します。

shell> sudo /Library/StartupItems/MySQL/MySQL start
(必要ならパスワードを入力)
(Control-D か "exit" を入れてシェルから抜ける)

Startup Item を使用しない場合は、以下のコマンドシーケンスを入力します。

shell> cd /usr/local/mysql
shell> sudo ./bin/mysqld_safe
(必要ならパスワードを入力)
(Control-Z)
shell> bg
(Control-D か "exit" を入れてシェルから抜ける)

これで、/usr/local/mysql/bin/mysql などを実行して MySQL サーバに接続することができるようになりました。

初めて MySQL をインストールした場合は、必ず、MySQL root ユーザのパスワードを設定してください。

パスワードの設定は、以下の 2 つのコマンドを使用して行います。

/usr/local/mysql/bin/mysqladmin -u root password <password>
/usr/local/mysql/bin/mysqladmin -u root -h `hostname` password <password>

2 行目の hostname コマンドは、必ず、バッククォート（`）で囲んでください。そうすることで、シェルは、このコマンドをその出力（このシステムのホスト名）に置き換えることができます。

以下のようにシェルのリソースファイルにエイリアスを追加して、コマンドラインから mysql および mysqladmin にアクセスすることもできます。

alias mysql '/usr/local/mysql/bin/mysql'
alias mysqladmin '/usr/local/mysql/bin/mysqladmin'

あるいは、たとえば以下の行を $HOME/.tcshrc に追加して、$PATH 環境変数に /usr/local/mysql/bin を追加することができます。

setenv PATH ${PATH}:/usr/local/mysql/bin

新しい MySQL PKG をインストールしても既存のインストールのディレクトリは削除されないことに注意してください。Mac OS X インストーラには、以前にインストールされたパッケージを適切にアップグレードするために必要な機能はまだ備わっていません。

旧バージョンの MySQL データベースファイルをコピーし、新しいバージョンを正常に起動した後、ディスク領域節約のために旧バージョンのインストールファイルを削除することをお勧めします。 さらに、/Library/Receipts/mysql-<version>.pkg にある旧バージョンの Package Receipt ディレクトリも削除してください。

バージョン 4.0.11 以降、Novell NetWare 向け MySQL サーバがバイナリパッケージ形式で提供されています。NetWare サーバは、MySQL をホストするために以下の要件を満たしていなければなりません。

NetWare 用バイナリパッケージは、http://www.mysql.com/downloads/ で入手できます。

NetWare 6.0 で MySQL を実行する場合は、コマンドラインで --skip-external-locking オプションを指定することを強くお勧めします。また、myisamchk は外部ロックを利用するので、myisamchk ではなく CHECK TABLE および REPAIR TABLE を使用する必要もあります。 NetWare 6.0 では、外部ロックに関する既知の問題があります。この問題は NetWare 6.5 では解決されています。

最新のバージョンとダウンロード手順については、MySQL のホームページ（http://www.mysql.com/）を参照してください。

主要ミラーは、http://mirrors.sunsite.dk/mysql/ にあります。

MySQL Web/ダウンロードミラーの最新の完全な一覧については、http://www.mysql.com/downloads/mirrors.html を参照してください。 このサイトでは、MySQL ミラーサイトになる方法と不適切なミラーや無効なミラーの報告方法についての情報も提供しています。

目的に合った MySQL パッケージをダウンロードした後、インストールする前に、そのパッケージが破損していないこと、そして改ざんされていないことを確認する必要があります。

MySQL AB は、MD5 checksums と、GnuPG による暗号化署名である GNU Privacy Guard の 2 種類の完全性チェック手段を提供しています。

MD5 Checksum の検証

パッケージをダウンロードした後、MD5 チェックサムが MySQL ダウンロードページに記載されているものと一致しているかどうかを確認してください。各パッケージには個別のチェックサムがあります。以下のコマンドを使用してチェックサムを検証することができます。

shell> md5sum <package>

注意: オペレーティングシステムによっては、md5sum コマンドがサポートされていないことがあります。一部のオペレーティングシステムでは、このコマンドを md5 という名前で呼んでいます。また、このコマンドをまったく提供していないオペレーティングシステムもあります。Linux では、このコマンドはさまざまなプラットフォームで使用できる GNU Text Utilities パッケージに組み込まれています。http://www.gnu.org/software/textutils/ からソースコードを入手することもできます。OpenSSL をインストールしている場合は、このコマンドの代わりに openssl md5 <package> コマンドを使用することもできます。md5 コマンドの DOS/Windows 実装は、http://www.fourmilab.ch/md5/ から入手できます。

例:

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

結果のチェックサムが、ダウンロードページで各パッケージの直下に記載されているものと一致しているかどうかを確認します。

GnuPG による署名チェック

パッケージの完全性を検証するためのより信頼性の高い方法は、暗号化署名を使用する方法です。MySQL AB は、GNU Privacy Guard（GnuPG）を使用します。これは、Phil Zimmermann が開発した非常に有名な Pretty Good Privacy（PGP）に代わる オープンソースのソフトウェアです。 OpenPGP/GnuPG の詳細と、GnuPG の入手方法およびご使用のシステムへのインストール方法については、http://www.gnupg.org/ および http://www.openpgp.org/ を参照してください。ほとんどの Linux ディストリビューションには、デフォルトで GnuPG がインストールされています。

MySQL 4.0.10（2003 年 2 月）以降、MySQL AB はダウンロード可能パッケージに GnuPG による署名を付けています。暗号化署名は、ファイルの完全性と信頼性を検証するためのより信頼性の高い方法です。

特定のパッケージの署名を検証するには、まず MySQL AB の 公開 GPG ビルドキー <build@mysql.com> のコピーを入手する必要があります。以下に記載したものを直接カットアンドペーストするか、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-----

このキーは、gpg --import を使用して公開 GPG キーリングにインポートすることができます。公開キーの処理方法については、GPG のマニュアルを参照してください。

公開ビルドキーをダウンロードしてインポートしたら、必要な MySQL パッケージと、それに対応する署名（これもダウンロードページから入手できます）をダウンロードします。 署名には、.asc というファイル名拡張子が付いています。たとえば、mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz の署名は、mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz.asc です。 パッケージと署名の両方のファイルが同じディレクトリに格納されていることを確認してから、以下のコマンドを実行して、パッケージファイルの署名を検証します。

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>"

"Good signature" というメッセージが表示されたら、問題ありません。

RPM による署名チェック

RPM パッケージの場合、別個の署名はありません。RPM パッケージには GPG 署名と MD5 チェックサムが組み込まれています。この署名と MD5 チェックサムは、以下のコマンドを実行して検証できます。

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

注意: RPM 4.1 を使用している場合、GPG 公開キーリングにインポートしたにもかかわらず、(GPG) NOT OK (MISSING KEYS: GPG#5072e1f5) というメッセージが表示されたら、まず RPM キーリングにキーをインポートする必要があります。RPM 4.1 では GPG キーリング（および GPG 自体）の使用が中止され、自身のキーリングが維持されています（これは、RPM がシステムワイドなアプリケーションであり、GPG 公開キーリングはユーザ固有のファイルであるためです）。MySQL 公開キーを RPM キーリングにインポートする場合は、以下のコマンドを使用してください。

shell> rpm --import <pubkey>

Example:

shell> rpm --import mysql_pubkey.asc

MD5 チェックサムまたは GPG 署名が一致しない場合は、まず別のミラーサイトからパッケージをもう一度ダウンロードしてみてください。再度、パッケージの完全性を検証できなかった場合は、そのパッケージの完全名と利用したダウンロードサイトを記載して、電子メールで当社にお知らせください（アドレスは <webmaster@mysql.com> または <build@mysql.com>）。

当社では GNU Autoconf を使用しているので、正常に機能する Posix スレッドおよび C++ コンパイラによってすべての最新のシステムに MySQL を移植することができます（クライアントコードだけをコンパイルする場合は、C++ コンパイラは必要ですがスレッドは不要です）。当社では、主に Linux（SuSE および Red Hat）、FreeBSD、および Sun Solaris （バージョン 8 および 9）上で MySQL ソフトウェアを使用および開発しています

多くのオペレーティングシステムでは、ネイティブスレッドは最新バージョンのOSでのみ有効であることに注意してください。MySQL は、以下のオペレーティングシステムとスレッドパッケージの組み合わせで正常にコンパイルすることが報告されています。

注意: すべてのシステムが、MySQL の実行に同じように適しているとは限りません。特定のプラットフォームが高負荷でミッションクリティカルな MySQL サーバにどのぐらい適しているかは、以下の要因によって決まります。

以上の基準から、現時点で MySQL を実行するのに最適なプラットフォームは、SuSE Linux 8.2、2.4 カーネル、および ReiserFS （または類似の Linux ディストリビューション）を搭載した x86 と、Solaris（2.7 ? 9）を搭載した SPARC です。FreeBSD は第 3 位ですが、スレッドライブラリが改善されればベストグループに仲間入りするはずです。また、MySQL がコンパイルされ、正常に動作する（安定性とパフォーマンスのレベルがまったく同じではないにしても）他のすべてのプラットフォームをいつの日かベストグループに含めることができるようになることを当社は切に希望しています。そのためには、MySQL が依存する OS やライブラリの開発者と協力して当社が努力する必要があります。それらのコンポーネントのいずれかを改善することに興味があり、その開発に影響を与える立場にあり、MySQL の動作を改善するために必要な事柄についての詳細な説明が必要なユーザは、MySQL の社内メーリングリストに電子メールをお送りください。 See 項1.7.1.1. 「MySQL メーリングリスト」。

上記の比較は、各 OS の全般的な優劣をつけるためのものではありません。ここでは、特定用途（つまり MySQL の実行）のために特定の OS を選択することに焦点をあてており、その点に関してのみプラットフォームを比較しています。これを念頭に置けば、この比較にさらに多くの論点を含めた場合は、結果は異なったものになります。ある OS が別の OS よりも優れている理由が、単に当社がそのプラットフォームのテストと最適化に他のプラットフォームよりも多くの労力を費やしたためだけであるということもあります。 ここでは、ご使用のセットアップ内で MySQL を使用するプラットフォームを決定する際に参考にしていただけるように当社の所見を述べているにすぎません。

最初に、最新の開発版リリースと最新の製品版（安定版）リリースのどちらを使用するかを決めます。

次に、ソースディストリビューションとバイナリディストリビューションのどちらを使用するかを決めます。ご使用のプラットフォーム用のバイナリディストリビューションがある場合、バイナリディストリビューションを使用してください。これは、一般的にソースディストリビューションよりもインストールが簡単なためです。

以下の場合は、ソースインストールを使用した方がうまく行く可能性があります。

MySQL の名前付けスキームでは、3 つの数字と 1 つのサフィックスで構成されるリリース番号が使用されます。たとえば、mysql-4.1.0-alpha のようなリリース名は、以下のように解釈されます。

MySQL 開発プロセスでは、段階の異なるさまざまなバージョンが共存します。当然、旧バージョンのシリーズの関連バグ修正は新バージョンに伝播されます。

MySQL のすべてのバージョンは、標準テストとベンチマークテストが行われ、比較的安全であることが確認されています。標準テストは、過去に見つかったすべてのバグをチェックするために時間の経過とともに拡張されているので、テストスィートは常に改良されています。

注意: すべてのリリースは少なくとも以下のテストが実行されています。

もう 1 つのテストは、当社が社内の実稼動環境で少なくとも 1 台のマシン上で最新の MySQL バージョンを使用することです。当社には 100 ギガバイトを超える処理用データがあります。

ここでは、バイナリディストリビューションおよびソースディストリビューションのインストールによって作成されるディレクトリのデフォルトレイアウトについて説明します。

バイナリディストリビューションは、選択したインストール場所（通常は /usr/local/mysql）でアンパックすることでインストールされ、その場所に以下のディレクトリを作成します。

ソースディストリビューションは、コンフィギャしてコンパイルした後にインストールされます。デフォルトでは、インストールステップによって、以下のサブディレクトリ内の /usr/local の下にファイルがインストールされます。

インストールディレクトリ内では、ソースインストールのレイアウトは、バイナリインストールのレイアウトとは以下のように異なります。

スクリプト scripts/make_binary_distribution を実行して、コンパイルされたソースディストリビューションから独自のバイナリインストールを作成できます。

MySQL AB 社内で MySQL は非常に急速に進化しており、当社は他の MySQL ユーザとこれを共有したいと考えています。他のユーザが必要としていると思われる非常に有用な機能がある場合は、リリースを作成します。

また、簡単に実装できる機能を求めているユーザの支援にも努めています。ライセンスユーザ、特に拡張電子メールサポート対象のユーザが何を要望しているかに注意し、これらのユーザを支援する努力を行っています。

ユーザは新しいリリースをダウンロードする必要はありません。本当に必要なものが新しいリリースに含まれている場合は、「News」のセクションで通知されます。 See 付録?D. MySQL Change History。

MySQL を更新する場合、当社は以下のポリシーを使用します。

現行の製品版リリースは、バージョン 4.0 です。アクティブな開発はすでにバージョン 4.1 および 5.0 に進んでいます。バージョン 4.0 のバグの修正と、3.23 シリーズの重大なバグの修正は今後も続けられます。 当社は、完全な開発凍結はよしとしません。これによって、バグ修正と "行うべき" ことが放置されることになるからです。"一部凍結" というのは、"すでに稼動しているものにほぼ間違いなく影響を与えない" 小さな変更が追加されることがあるということを意味します。

MySQL では、大部分の他製品とは少し異なる名前付けスキームが使用されます。 一般に、新しいバージョンに置き換えられることなく 2 週間公開されたバージョンは、使用しても比較的安全です。 See 項2.2.4. 「使用すべき MySQL のバージョン」。

当社は、リリースにバグがないようにするために多くの時間と労力を費やしています。 当社の知る限り、既知の '重大な' 再現可能なバグがある MySQL バージョンは 1 つもリリースされていません。

重大なバグとは、通常の使用で MySQL をクラッシュさせる、一般的なクエリに対して誤った応答を返すバグ、またはセキュリティに問題があるバグです。

設計上の決定に依存する未解決の障害、バグ、問題はすべて文書化されています。 See 項1.8.6. 「MySQL の既知のエラーと設計上の問題」。

当社の目標は、安定版の MySQL が不安定になるような危険を冒すことなく、修正可能なものはすべて修正することです。場合によって、これは、開発版の問題は修正できるが、安定版（製品版）の問題は修正できないということを意味します。当然、そのような問題は、ユーザに知らせるために文書化されます。

以下に、当社のビルドプロセスの仕組みを説明します。

MySQL AB は、サービスとして MySQL の一連のバイナリディストリビューションを提供します。これらのバイナリディストリビューションは、社内でコンパイルするか、ユーザが当社にマシンへのアクセスを提供してくれる場所でコンパイルされます。

プラットフォーム固有のパッケージ形式で提供するバイナリ（項2.1. 「標準 MySQL のクイックインストール」 を参照）のほかに、tar 形式の圧縮アーカイブ（.tar.gz）によってさまざまなプラットフォーム用のバイナリディストリビューションも提供します。

これらのディストリビューションは、Build-tools/Do-compile スクリプトを使用して生成されます。このスクリプトは、ソースコードをコンパイルし、scripts/make_binary_distribution を使用してバイナリ tar.gz アーカイブを作成します。これらのバイナリは、以下のコンパイラとオプションによってコンフィギャおよびビルドされます。

MySQL AB の開発システムでビルドされるバイナリは以下のとおりです。

以下のバイナリは、他のユーザによって MySQL AB に提供されたサードパーティのシステム上でビルドされています。これらのバイナリは、好意によって提供されています。MySQL AB は、これらのシステムを完全に管理しているわけではないので、これらのシステム上でビルドされたバイナリに対しては限られたサポートしか提供できません。

以下のコンパイルオプションは、MySQL AB がかつて提供していたバイナリパッケージに使用されていたものです。これらのバイナリは現在では更新されていませんが、参考のためにここにコンパイルオプションを記載します。

上記のいずれかの設定に関してさらに最適なオプションをお持ちの方は、そのオプションを MySQL 社内メーリングリストに随時お送りください。 See 項1.7.1.1. 「MySQL メーリングリスト」。

MySQL バージョン3.22 より前の RPM ディストリビューションは、ユーザによる寄贈です。バージョン 3.22 以降の RPM は、MySQL AB によって作成されています。

MySQL のデバッグバージョンをコンパイルする場合は、前述の configure 行に --with-debug オプションまたは --with-debug=full オプションを追加し、すべての -fomit-frame-pointer オプションを削除してください。

Windows ディストリビューションについては、項2.1.1. 「Windows への MySQL のインストール」 を参照してください。

ここでは、さまざまなプラットフォーム用の MySQL バイナリディストリビューション（.tar.gz アーカイブ）について説明します（詳細な一覧については、項2.2.8. 「MySQL AB がコンパイルした MySQL バイナリ」 を参照してください）。

これらの一般的なパッケージのほかに、選択したプラットフォームのプラットフォーム固有のパッケージ形式のバイナリも提供しています。 これらのパッケージのインストール方法の詳細については、項2.1. 「標準 MySQL のクイックインストール」を参照してください。

一般的な MySQL バイナリディストリビューションは、gzip 形式で圧縮された GNU tar アーカイブ（.tar.gz）としてパッケージ化されています。MySQL バイナリディストリビューションをインストールするためには以下のツールが必要です。

問題が発生した場合は、MySQL メーリングリストに質問を投稿するときに、必ず mysqlbug を使用してください。その問題がバグでない場合でも、mysqlbug は、他のユーザが同じ問題を解決する際に役立つシステム情報を収集します。mysqlbug を使用しないと、問題を解決できる可能性が小さくなります。ディストリビューションをアンパックすると、bin ディレクトリに mysqlbug が格納されます。 See 項1.7.1.3. 「バグまたは問題を報告する方法」。

MySQL バイナリディストリビューションをインストールして使用するために実行する必要のある基本的なコマンドは、以下のとおりです。

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 &

4.0 より前のバージョンの MySQL を使用している場合は、最後のコマンドの bin/mysqld_safe を bin/safe_mysqld に置き換えてください。

DBI および DBD-mysql Perl モジュールをインストールしている場合は、bin/mysql_setpermission スクリプトを使用して新しいユーザを追加できます。

以下に詳細な説明を示します。

バイナリディストリビューションをインストールするには、以下のステップに従って処理を行った後、項2.4. 「インストール後の設定とテスト」 に進み、インストール後の設定とテストを行います。

すべてのものをアンパックしてインストールしたら、ディストリビューションの初期化とテストを行ってください。

以下のコマンドで MySQL サーバを起動することができます。

shell> bin/mysqld_safe --user=mysql &

4.0 より前のバージョンの MySQL を使用している場合は、このコマンドの bin/mysqld_safe を bin/safe_mysqld に置き換えてください。

次に、項4.8.2. 「mysqld_safe（mysqld のラッパ）」 に進み、See 項2.4. 「インストール後の設定とテスト」 を参照してください。

MySQL ソースディストリビューションをインストールするために実行する必要のある基本的なコマンドは、以下のとおりです。

shell> groupadd mysql
shell> useradd -g mysql mysql
shell> gunzip < mysql-VERSION.tar.gz | tar -xvf -
shell> cd mysql-VERSION
shell> ./configure --prefix=/usr/local/mysql
shell> make
shell> make install
shell> scripts/mysql_install_db
shell> chown -R root  /usr/local/mysql
shell> chown -R mysql /usr/local/mysql/var
shell> chgrp -R mysql /usr/local/mysql
shell> cp support-files/my-medium.cnf /etc/my.cnf
shell> /usr/local/mysql/bin/mysqld_safe --user=mysql &

バージョン 4.0 より前の MySQL を使用している場合は、最後のコマンドの bin/mysqld_safe を bin/safe_mysqld に置き換えてください。

InnoDB テーブルのサポートが必要な場合は、/etc/my.cnf ファイルを編集して、innodb_... で始まるパラメータの前にある # 文字を削除してください。 See 項4.1.2. 「my.cnf オプション設定ファイル」 と 項7.5.3. 「InnoDB 起動オプション」 を参照してください。

ソース RPM から開始する場合は、以下のコマンドを実行します。

shell> rpm --rebuild --clean MySQL-VERSION.src.rpm

これによって、インストールできるバイナリ RPM が作成されます。

DBI および DBD-mysql Perl モジュールをインストールしている場合は、bin/mysql_setpermission スクリプトを使用して新しいユーザを追加できます。

以下に詳細な説明を示します。

ソースディストリビューションをインストールするには、以下のステップに従って処理を行った後、項2.4. 「インストール後の設定とテスト」 に進み、ポストインストール初期化とテストを行います。

すべてのものをインストールしたら、以下のコマンドを使用してディストリビューションの初期化とテストを行ってください。

shell> /usr/local/mysql/bin/mysqld_safe --user=mysql &

バージョン 4.0 より前の MySQL を使用している場合は、このコマンドの mysqld_safe を safe_mysqld に置き換えてください。

そのコマンドが、mysqld daemon ended というエラーですぐに失敗した場合は、ファイル mysql-data-directory/'hostname'.err に何らかの情報が記述されています。 原因としては、すでに別の mysqld サーバを実行していることが考えられます。 See 項4.2. 「同じマシン上で複数の MySQL サーバを実行する」。

次に、項2.4. 「インストール後の設定とテスト」 に進みます。

パッチは、メーリングリストまたは MySQL の Web サイト（http://www.mysql.com/downloads/patches.html）の「patches」エリアにときどき公開されます。

メーリングリストにあるパッチを適用するには、パッチが含まれたメッセージをファイルに保存し、MySQL ソースツリーの最上位ディレクトリに移動して以下のコマンドを実行します。

shell> patch -p1 < patch-file-name
shell> rm config.cache
shell> make clean

FTP サイトにあるパッチは、プレーンテキストファイルまたは gzip で圧縮されたファイルとして配布されます。プレーンテキストのパッチの適用は、メーリングリストのパッチの箇所で説明した方法で行います。圧縮されたパッチを適用するには、MySQL ソースツリーの最上位ディレクトリに移動して、以下のコマンドを実行します。

shell> gunzip < patch-file-name.gz | patch -p1
shell> rm config.cache
shell> make clean

パッチを適用した後に、通常のソースインストール手順に従いますが、./configure ステップから開始します。make install ステップを実行したら、MySQL サーバを再起動します。

make install を実行する前に、現在稼動しているサーバを停止させる必要があります（サーバを停止させるには mysqladmin shutdown を使用します）。一部のシステムでは、新しいバージョンのプログラムが現在実行されているバージョンを置き換える場合は、新しいバージョンのインストールが許可されないことがあります。

configure スクリプトを使用すると、MySQL ディストリビューションの設定を自由に調整できます。設定方法の調整は、通常は configure コマンドラインでオプションを使用して行います。また、環境変数を使用して configure を調整することもできます。See 付録?F. 環境変数。 configure がサポートするオプションの一覧が必要な場合は、以下のコマンドを実行します。

shell> ./configure --help

ここでは、広く使用されている configure オプションの一部を説明します。

注意:このセクションは、当社の新しいコードのテストに協力することに関心のある場合にのみお読みください。MySQL をビルドしてシステム上で稼動させるだけの場合は、標準のリリースディストリビューション（ソースディストリビューションまたはバイナリディストリビューション）を使用してください。

最新の開発ソースツリーを入手するには、以下の説明に従ってください。

ChangeSet、コメント、ソースコードは、たとえば MySQL 4.1 の場合は http://mysql.bkbits.net:8080/mysql-4.1 で検索することもできます。

マニュアルは、独立したツリーに格納されています。このツリーは、以下のコマンドを使用してコピーすることができます。

shell> bk clone bk://mysql.bkbits.net/mysqldoc mysqldoc

MySQL Control Center と Connector/ODBC の公開 BitKeeper ツリーもあります。これらのツリーは、それぞれ以下のコマンドでコピーできます。

MySQL Control Center をコピーするには、以下のコマンドを使用してください。

shell> bk clone http://mysql.bkbits.net/mysqlcc mysqlcc

Connector/ODBC をコピーするには、以下のコマンドを使用してください。

shell> bk clone http://mysql.bkbits.net/myodbc3 myodbc3

すべての MySQL プログラムは、gcc を使用して、Solaris または Linux 上で警告を受け取ることなくきれいにコンパイルできます。他のシステム上では、システムインクルードファイルの違いが原因で警告が発生することがあります。MIT-pthreads を使用している場合に発生する可能性のある警告については、項2.3.6. 「MIT-pthreads に関する注意事項」 を参照してください。それ以外の問題については、以下の一覧をチェックしてください。

多くの問題は、解決に再 configure が必要です。再 configure が必要な場合は、以下の点に留意してください。

古い検出情報やオブジェクトファイルが使用されるのを防ぐために、configure を再実行する前に以下のコマンドを実行します。

shell> rm config.cache
shell> make clean

または、make distclean を実行します。

以下の一覧で、MySQL のコンパイル時によく発生することがわかっているいくつかの問題を説明します。

ここでは、MIT-pthreads の使用に関係するいくつかの問題を説明します。

注意: Linux では、MIT-pthreads を使用しないで、インストールされている LinuxThreads 実装を使用してください。 See 項2.6.2. 「Linux の注意事項（すべての Linux バージョン）」。

システムにネイティブスレッドサポートが用意されていない場合は、MIT-pthreads パッケージを使用して MySQL をビルドする必要があります。そのようなシステムとしては、旧バージョンの FreeBSD システム、SunOS 4.x、Solaris 2.4 以前などがあります。 See 項2.2.3. 「MySQL がサポートしているオペレーティングシステム」。

注意: MySQL 4.0.2 からは、ソースディストリビューションに MIT-pthreads は含まれていません。このパッケージが必要な場合は、http://www.mysql.com/Downloads/Contrib/pthreads-1_60_beta6-mysql.tar.gz から別にダウンロードしてください。

ダウンロードしたら、このソースアーカイブを MySQL ソースディレクトリの最上位で展開します。これによって、mit-pthreads というサブディレクトリが新しく作成されます。

ここでは、Windows 上でバージョン 4.1 以降のソースから MySQL バイナリをビルドする方法を説明します。標準のソースディストリビューションまたは最新の開発ソースが格納されている BitKeeper ツリーからバイナリをビルドする場合の手順が記載されています。

注意: ここに記載されている手順は、最新のソースディストリビューションまたは BitKeeper ツリーで入手した MySQL を Windows 上でテストするユーザだけを対象としています。 自分でソースからビルドした MySQL サーバを実稼動環境で使用することはお勧めしません。通常、最も望ましいのは、MySQL AB が特に Windows 上で最適なパフォーマンスを達成するようにビルドした、プリコンパイルされた MySQL バイナリディストリビューションを使用することです。 バイナリディストリビューションのインストール手順については、項2.1.1. 「Windows への MySQL のインストール」 を参照してください。

Windows 上で MySQL をビルドするには、使用している Windows システムに以下のコンパイラとリソースがなければなりません。

また、Windows 用の MySQL ソースディストリビューションも必要です。MySQL バージョン 4.1 以降のソースディストリビューションを入手する方法は、以下の2 とおりです。

Windows ソースディストリビューションを使用する場合は、直接 項2.3.7.1. 「VC++ を使用した MySQL のビルド」 に進んでください。BitKeeper ツリーからビルドする場合は、項2.3.7.2. 「最新の開発ソースから Windows ソースパッケージを作成する」 に進んでください。

予想通りに動作しないものを見つけた場合や、Windows での現在のビルドプロセスの改良方法に関して提案がある場合は、win32 メーリングリストにメッセージを送ってください。 See 項1.7.1.1. 「MySQL メーリングリスト」。

mysql_install_db スクリプトの目的は、新しい MySQL 権限テーブルを生成することです。このスクリプトがその他のデータに影響を及ぼすことはありません。 MySQL 権限テーブルがすでにインストールされている場合は、何も行いません。

権限テーブルを作成し直す場合は、mysqld サーバを停止して（サーバが稼動している場合）、以下のようなコマンドを実行します。

shell> mv mysql-data-directory/mysql mysql-data-directory/mysql-old
shell> mysql_install_db

ここでは、mysql_install_db の実行時に発生する可能性のある問題について説明します。

トランザクション（InnoDB、BDB）をサポートするテーブルを使用する場合は、最初に my.cnf ファイルを作成して、使用する予定のテーブル型用の起動オプションを設定しておく必要があります。 See 章?7. MySQL のテーブル型。

通常は、以下のいずれかの方法で mysqld サーバを起動します。

起動した mysqld デーモンは、ディレクトリをデータディレクトリに変更します。このディレクトリで、mysqld は、ログファイルと pid （プロセスID）ファイルを書き込み、データベースを検索します。

データディレクトリ(datadir 変数)の場所は、ディストリビューションのコンパイル時に組み込まれます。ただし、mysqld が実際に存在するシステム上の場所以外の場所にデータディレクトリがあると、mysqld は正しく動作しません。パスに問題がある場合は、--help オプションを指定して mysqld を起動して、mysqld が許可するオプションとデフォルトのパス設定を確認することができます。mysqldへのコマンドライン引数として正しいパス名を指定して、デフォルト設定を無効にすることができます（これらのオプションは、mysqld_safe でも同様に使用できます）。

通常、mysqld に指示する必要があるのは、MySQL がインストールされているベースディレクトリだけです。ベースディレクトリの指定は、--basedir オプションを使用して行うことができます。また、--help を使用して、パスオプションを変更した場合の影響をチェックすることもできます（注意: --help は、mysqld コマンドラインの最後に指定する必要があります）。以下に例を示します。

shell> EXECDIR/mysqld --basedir=/usr/local --help

必要なパス設定を決定したら、--help オプションを指定しないでサーバを起動します。

どの方法でサーバを起動した場合でも、サーバが正常に起動しないときは、ログファイルをチェックして原因を突き止めることができるかどうか確認します。ログファイルは、データディレクトリ（通常、バイナリディストリビューションの場合は /usr/local/mysql/data、ソースディストリビューションの場合は /usr/local/var、Windows 上では \mysql\data\mysql.err）です。データディレクトリ内で host_name.err や host_name.log の形式の名前を持つファイルを探します。この場合、host_name は、使用しているサーバホストの名前です。次に、以下のコマンドを実行して、それらのファイルの最後の数行をチェックします。

shell> tail host_name.err
shell> tail host_name.log

ログファイル内で以下のような記述を探します。

000729 14:50:10  bdb:  Recovery function for LSN 1 27595 failed
000729 14:50:10  bdb:  warning: ./test/t1.db: No such file or directory
000729 14:50:10  Can't init databases

これは、--bdb-no-recover を指定しないで mysqld を起動したことと、Berkeley DB がデータベースをリカバリするときにログファイルに問題があることを発見したことを意味しています。続行できるようにするには、データベースディレクトリにある既存の Berkeley DB のログファイルを、後で調べることができるような他の場所に移動します。ログファイルには、log.0000000001 という名前が付いています。この場合、数字は時間の経過とともに増えます

BDB テーブルをサポートしている mysqld を起動しようとしてコアを吐いた場合は、BDB リカバリログに問題があるかもしれません。その場合は、--bdb-no-recover を指定して mysqld を起動してみます。この方法でサーバが正常に起動した場合は、データディレクトリからすべての log.* ファイルを削除して、もう一度 mysqld を起動してみます。

以下のエラーが表示された場合は、mysqld が使用しようとした TCP/IP ポートまたはソケットファイルを、他のプログラム（または別の mysqld サーバ）がすでに使用していることを意味します。

Can't start server: Bind on TCP/IP port: Address already in use
  か
Can't start server: Bind on unix socket...

ps を使用して、別の mysqld サーバが稼動していないことを確認します。別のサーバが稼動していないことが確認できたら、コマンド telnet ホスト名 TCP/IPポート番号 を実行して、Enter キーを 2、3 回押します。telnet: Unable to connect to remote host: Connection refused のようなエラーメッセージが出力されない場合は、mysqld が使用しようとした TCP/IP ポートは他のプログラムによって使用されています。 項2.4.1. 「mysql_install_db の実行に関する問題」 および 項4.2. 「同じマシン上で複数の MySQL サーバを実行する」 を参照してください。

mysqld が現在稼動している場合は、以下のコマンドを実行して、mysqld が使用しているパス設定を調べることができます。

shell> mysqladmin variables

または

shell> mysqladmin -h 'your-host-name' variables

mysqld の起動時に Errcode 13（Permission deniedを表す）が表示された場合は、MySQL データベースまたはログディレクトリ内のファイルの読み取り/書き込み権限がなかったことを意味します。この場合、Unix root アカウントで mysqld を起動するか、関連するファイルおよびディレクトリを mysqld を実行する Unix アカウントが使用できるように、それらのファイルおよびディレクトリのアクセス権を変更します。

mysqld_safe によってサーバが起動されたのに、そのサーバに接続できない場合は、/etc/hosts に以下のようなエントリがあるかどうかを確認します。

127.0.0.1       localhost

この問題は、正常に機能するスレッドライブラリがなく、MySQL がMIT-pthreads を使用するようにコンフィギャされているシステムで発生します。

mysqld を起動させることができない場合は、トレースファイルを作成して問題を見つけます。 See 項E.1.2. 「トレースファイルの作成」。

InnoDB テーブルを使用している場合は、項7.5.3. 「InnoDB 起動オプション」 を参照してください。

BDB（Berkeley DB）テーブルを使用している場合は、項7.6.3. 「BDB 起動オプション」 をよく理解しておいてください。

mysql.server スクリプトと mysqld_safe スクリプトを使用すると、システムの起動時にサーバを自動的に起動することができます。mysql.server は、サーバを停止する場合にも使用できます。

mysql.server スクリプトに start 引数または stop 引数を指定して起動すると、サーバを起動または停止することができます。

shell> mysql.server start
shell> mysql.server stop

mysql.server は、MySQL インストールディレクトリの下の share/mysql ディレクトリか、MySQL ソースツリーの support-files ディレクトリにあります。

注意: Linux RPM パッケージ（MySQL-server-VERSION.rpm）を使用している場合は、mysql.server スクリプトは /etc/init.d/mysql としてすでにインストールされています。したがって、手動でこのスクリプトをインストールする必要はありません。Linux RPM パッケージの詳細については、項2.1.2. 「Linux への MySQL のインストール」 を参照してください。

Mac OS X では、別の MySQL Startup Item パッケージをインストールして、システムブートアップ時に MySQL が自動的に起動できるようにすることができます。 詳細については、項2.1.3. 「Mac OS X への MySQL のインストール」 を参照してください。

mysql.server は、サーバを起動する前にディレクトリを MySQL インストールディレクトリに変更してから、mysqld_safe を起動します。 インストールしたバイナリディストリビューションが標準以外の場所にある場合は、mysql.server を編集する必要があります。mysqld_safe を実行する前に適切なディレクトリに変更する（cd）ように、mysql.server を修正します。サーバを特定のユーザとして実行する場合は、このセクションで説明するように適切な user 行を /etc/my.cnf ファイルに追加します。

mysql.server stop は、サーバにシグナルを送って停止させます。 mysqladmin shutdown を実行して、サーバを手動で停止させることもできます。

/etc/rc* ファイル内の適切な場所にこれらの起動コマンドおよび停止コマンドを追加する必要があります。

最新の Linux ディストリビューションでは、mysql.server ファイルを /etc/init.d ディレクトリ（旧バージョンの Red Hat システムの場合は /etc/rc.d/init.d）にコピーするだけで済みます。その後、以下のコマンドを実行して、システムブート時に MySQL が起動できるようにします。

shell> chkconfig --add mysql.server

FreeBSD では、通常、起動スクリプトは /usr/local/etc/rc.d/ に格納されます。 rc(8) マニュアルページには、このディレクトリにあるスクリプトの basename がシェルグロブパターン *.sh にマッチし、実行可能である場合のみ、実行されると述べられています。このディレクトリ内のその他のファイルやディレクトリは、自動的に無視されます。つまり、FreeBSD では、自動起動を有効にするには、ファイル mysql.server を /usr/local/etc/rc.d/mysql.server.sh としてインストールする必要があります。

一部のオペレーティングシステムでは、上記の方法の代わりに、/etc/rc.local または /etc/init.d/boot.local を使用して、ブートアップ時にその他のサービスを起動することもできます。この方法で MySQL を起動するには、以下のような記述を末尾に追加します。

shell> /bin/sh -c 'cd /usr/local/mysql; ./bin/mysqld_safe --user=mysql &'

グローバル /etc/my.cnf ファイルに mysql.server のオプションを追加することもできます。標準的な /etc/my.cnf ファイルは、以下のようになります。

[mysqld]
datadir=/usr/local/mysql/var
socket=/var/tmp/mysql.sock
port=3306
user=mysql

[mysql.server]
basedir=/usr/local/mysql

mysql.server スクリプトは、datadir、basedir、および pid-file の各オプションを認識します。.

以下の表に、各起動スクリプトが、オプション設定ファイルから読み取るオプショングループを示します。

下位互換性のために、mysql.server は [mysql_server] グループも読み取り、mysqld_safe は [safe_mysqld] グループも読み取ります。しかし、これらの代わりに [mysql.server] グループと [mysqld_safe] グループを使用するようにオプション設定ファイルを更新する必要があります。

See 項4.1.2. 「my.cnf オプション設定ファイル」。

MySQL 4.0 と MySQL 4.1 では、重大なバグを修正し、MySQL と ANSI SQL 標準との互換性を向上させるためにいくつかの目立つ動作が変更されています。これらの変更は、アプリケーションに影響を及ぼすことがあります。

一部の 4.1 の動作は、完全に 4.1 にアップグレードする前に 4.0 でテストすることができます。比較的最近の MySQL 4.0 リリース（4.0.12 以降）には、mysqld 用の --new 起動オプションが追加されています。

このオプションを使用すると、最も重大な変更が行われた 4.1 の動作が提供されます。 SET @@new=1 コマンドを使用して特定のクライアント接続に対してこれらの動作を有効にしたり、有効になっている場合は SET @@new=0 コマンドを使用して無効にすることができます。

4.1 の変更点によって影響を受けると思われる場合は、4.1 にアップグレードする前に、最新の MySQL 4.0 バージョンをダウンロードして、設定ファイルに以下を追加し、--new オプションを指定してその MySQL を実行することをお勧めします。

[mysqld-4.0]
new

このようにすれば、4.0 上で、新しい機能を動作させて、アプリケーションがそれらと連携して正常に機能するかどうかを、確認することができます。これは、4.1 以降への完全アップグレードを行うときに、苦労せずにスムーズに移行するのに役に立ちます。上記の方法でこれを行うと、誤って --new オプションを指定して 4.1 バージョンを実行することはありません。

以下では、アプリケーションに影響を及ぼす可能性のある変更点や、バージョン 4.1 にアップグレードするときに注意する必要のある変更点について説明します。

一般に、以前の MySQL バージョンから 4.1 にアップグレードする場合は、以下のステップを実行する必要がある。

4.1 では、より強力なセキュリティを実現するようにパスワードのハッシュメカニズムが変更されています。ただし、4.0 以前のクライアントライブラリを使用するクライアントがある場合に、互換性の問題が発生することがあります（4.1 にアップグレードされていないリモートホストからクライアントが接続するような状況では 4.0 クライアントがある可能性が非常に高いです）。考えられるいくつかのアップグレード方針を以下に示します。旧バージョンのクライアントとの互換性の目標とセキュリティの目標の間でさまざまなトレードオフが存在します。

クライアント認証とパスワード変更操作に関係するパスワードハッシュの予備知識については、項4.3.11. 「MySQL 4.1 のパスワードハッシュ」 を参照してください。

一般に、以前の MySQL バージョンから 4.0 にアップグレードする場合は、以下を実行する必要があります。

上記の処理を行わなくても MySQL 4.0 は動作しますが、新しいセキュリティ特権を使用できないため、後で MySQL 4.1 以降にアップグレードするときに問題が発生することがあります。ISAM ファイル形式は、MySQL 4.0 では引き続き機能しますが、廃止予定であり、MySQL 4.1 では無効化されます（デフォルトではコンパイルされない）。代わりに、MyISAM テーブルが使用されます。

旧バージョンのクライアントは、バージョン 4.0 サーバと支障なく連携して動作します。

上記の処理を行った場合でも、MySQL 4.0 シリーズで問題が発生したときは、MySQL 3.23.52 以降にダウングレードできます。その場合、mysqldump を使用して、フルテキストインデックスを使用するすべてのテーブルをダンプし、ダンプファイルを 3.23 サーバに再ロードする必要があります。 これは、4.0 ではフルテキストインデックス作成に新しい形式が使用されるためです。

以下では、バージョン 4.0 にアップグレードするときに注意する必要のある点についてさらに詳しく説明します。

Windows 上で MySQL サーバを実行する場合は、項2.5.8. 「Windows 上での MySQL のアップグレード」 も参照してください。レプリケーションを使用する場合は、項4.11.2. 「レプリケーション実装の概要」 も参照してください。

MySQL バージョン 3.23 は、新しい MyISAM 型と以前の ISAM 型のテーブルをサポートします。バージョン 3.23 で以前のテーブルを使用する場合に、それらのテーブルを変換する必要はありません。デフォルトでは、新しいテーブルはすべて、MyISAM 型で作成されます（ただし、--default-table-type=isam オプションを指定して mysqld を起動した場合を除きます）。ISAM テーブルは、ALTER TABLE table_name TYPE=MyISAM または Perl スクリプト mysql_convert_table_format を使用して MyISAM 形式に変換することができます。

バージョン 3.22 および 3.21 のクライアントは、バージョン 3.23 サーバと支障なく連携して動作します。

以下では、バージョン 3.23 にアップグレードするときに注意する必要のある事項について説明します。

バージョン 3.21 とバージョン 3.22 の間では互換性に影響するような変更は行われていません。 唯一の落とし穴は、DATE 型カラムで作成された新しいテーブルでは、新しい方法で日付が格納されることです。旧バージョンの mysqld からこれらの新しいカラムにアクセスすることはできません。

MySQL バージョン 3.22 をインストールした後に、新しいサーバを起動して、mysql_fix_privilege_tables スクリプトを実行する必要があります。このスクリプトによって、GRANT コマンドを使用するために必要な新しい権限が追加されます。この処理をしないと、ALTER TABLE、CREATE INDEX、または DROP INDEX を使用しようとしたときに、Access denied が返されます。権限テーブルの更新の手順については、項2.5.6. 「権限テーブルのアップグレード」 を参照してください。

mysql_real_connect() への C API インタフェースは変更されました。この関数を呼び出す旧バージョンのクライアントプログラムがある場合は、新しい db 引数に 0 を指定します（または db 要素を送信するようにクライアントのコードを作成し直します）。また、mysql_real_connect() を呼び出す前に mysql_init() を呼び出す必要もあります。この変更は、新しい mysql_options() 関数が MYSQL ハンドラ構造にオプションを保存できるようにするために行われました。

mysqld 変数 key_buffer は、key_buffer_size という名前に変更されました。ただし、起動ファイルでは以前の名前を引き続き使用することができます。

バージョン 3.20.28 より前のバージョンを実行していて、バージョン 3.21 に切り替える場合は、以下のことを行う必要があります。

--old-protocol オプションを指定して mysqld バージョン 3.21 サーバを起動して、そのサーバをバージョン 3.20 ディストリビューションからのクライアントと共に使用することができます。この場合、新しいクライアント関数 mysql_errno() は、サーバエラーは返さず、CR_UNKNOWN_ERROR だけを返します（ただし、この関数はクライアントエラーに対しては機能します）。また、サーバは、新しい方式ではなく、3.21 より前の古い password() チェック方式を使用します。

mysqld に --old-protocol オプションを使用しない場合は、以下の変更を行う必要があります。

MySQL バージョン 3.20.28 以降では、クライアントに影響を及ぼすことなく新しい user テーブル形式を処理することができます。バージョン 3.20.28 より前の MySQL バージョンを使用している場合、user テーブルを変換すると、パスワードはその MySQL では無効になります。したがって、安全のために、最初にバージョン 3.20.28 以上にアップグレードしてから、バージョン 3.21 にアップグレードしてください。

新しいクライアントコードは 3.20.x mysqld サーバと連携して動作します。したがって、3.21.x で問題が発生した場合は、クライアントを再コンパイルしなくても既存の 3.20.x サーバを使用することができます。

mysqld に --old-protocol オプションを使用しないと、旧バージョンのクライアントは接続できず、以下のエラーメッセージを出力します。

ERROR: Protocol mismatch. Server Version = 10 Client Version = 9

新しい Perl DBI/DBD インタフェースは、旧バージョンの mysqlperl インタフェースもサポートします。mysqlperl を使用する場合に唯一変更する必要があるのは、connect() 関数の引数です。 新しい引数は、host、database、user、および password です（注意: user 引数と password 引数は順序が入れ替わりました）。 See 項11.5.2. 「DBI インタフェース」。

以下の変更は、旧バージョンのアプリケーションのクエリに影響を及ぼすことがあります。

一部のリリースでは、権限テーブル（mysql データベース内のテーブル）の構造が変更され、新しい権限または機能が追加されています。新しいバージョンの MySQL に更新したときに権限テーブルが確実に最新のものであるようにするには、権限テーブルも更新する必要があります。

Unix システムまたは Unix ライクなシステムでは、以下のように mysql_fix_privilege_tables スクリプトを実行して権限テーブルを更新します。

shell> mysql_fix_privilege_tables

このスクリプトは、サーバの稼動中に実行しなければなりません。このスクリプトは、ローカルホスト上で稼動しているサーバに root として接続します。 root アカウントがパスワードを必要とする場合は、コマンドラインでパスワードを指定します。MySQL 4.1 以降のバージョンの場合は、以下のようにパスワードを指定します。

shell> mysql_fix_privilege_tables --password=root_password

MySQL 4.1 より前のバージョンの場合は、以下のようにパスワードを指定します。

shell> mysql_fix_privilege_tables root_password

mysql_fix_privilege_tables スクリプトは、権限テーブルを現行の形式に変換するために必要な処理を実行します。スクリプトの実行中にいくつかの Duplicate column name 警告が表示されることがあります。これらの警告は無視してかまいません。

スクリプトの実行後に、サーバを停止してから、再起動します。

Windows システムでは、MySQL 4.0.15 までは、権限テーブルを簡単に更新する方法はありません。バージョン 4.0.15 以降では、mysql クライアントを使用して実行できる mysql_fix_privilege_tables.sql SQL スクリプトが MySQL ディストリビューションに含まれています。MySQL が C:\mysql にインストールされている場合、コマンドは以下のようになります。

C:\mysql\bin> mysql -u root -p mysql

mysql> SOURCE C:\mysql\scripts\mysql_fix_privilege_tables.sql

MySQL がこれ以外のディレクトリにインストールされている場合は、パス名をそれに合わせて変更してください。

このコマンドは、root のパスワードの入力を求めるプロンプトを表示します。プロンプトが表示されたらパスワードを入力します。

Unix の手順の場合と同様に、mysql が mysql_fix_privilege_tables.sql スクリプトのステートメントを処理しているときにいくつかの Duplicate column name 警告が表示されることがあります。これらの警告は、無視してかまいません。

スクリプトの実行後に、サーバを停止してから、再起動します。

MySQL バージョン 3.23 を使用している場合、同じ浮動小数点形式をサポートする異なるアーキーテクチャ間で、MyISAM テーブルの .frm、.MYI、および .MYD の各ファイルをコピーできます（MySQL はバイトスワップの問題を処理します）。 See 項7.1. 「MyISAM テーブル」。

MySQL ISAM データファイルおよびインデックスファイル（それぞれ、.ISD および *.ISM）は、アーキーテクチャ依存であり、場合によっては OS にも依存します。現在のマシンとは異なるアーキーテクチャまたは OS を持つ別のマシンにアプリケーションを移動したい場合、そのマシンにファイルを単純にコピーするだけでは、データベースを移動することはできません。代わりに、mysqldump を使用してください。

mysqldump は、デフォルトで SQL ステートメントが格納されたファイルを作成します。 ファイルを移動先のマシンに転送し、mysql クライアントにデータとして入力します。

mysqldump --help を実行して、使用可能なオプションを確認します。 新しいバージョンの MySQL にデータを移動する場合は、高速でコンパクトなダンプを行うために、新しいバージョンで mysqldump --opt を使用してください。

マシン間でデータベースを移動するための最も簡単な（ただし、最も迅速というわけではありません）方法は、データベースが置かれているマシンで以下のコマンドを実行することです。

shell> mysqladmin -h 'other hostname' create db_name
shell> mysqldump --opt db_name \
        | mysql -h 'other hostname' db_name

低速のネットワークを通じてリモートマシンのデータベースをコピーする場合は、以下のコマンドを使用します。

shell> mysqladmin create db_name
shell> mysqldump -h 'other hostname' --opt --compress db_name \
        | mysql db_name

結果をファイルに保存し、そのファイルを移動先のマシンに転送して、そのマシン上のデータベースにロードすることもできます。たとえば、以下のように、移動元のマシン上のファイルにデータベースをダンプします。

shell> mysqldump --quick db_name | gzip > db_name.contents.gz

（この例で作成されるファイルは圧縮されています。）データベースの内容が格納されたファイルを移動先のマシンに転送し、そのマシン上で以下のコマンドを実行します。

shell> mysqladmin create db_name
shell> gunzip < db_name.contents.gz | mysql db_name

また、mysqldump と mysqlimport を使用してデータベースを転送することもできます。 大きなテーブルの場合、この方法を使用すると、mysqldump だけを使用した場合よりもはるかに処理が速くなります。 以下のコマンドでは、DUMPDIR は、mysqldump からの出力を格納するのに使用するディレクトリの完全パス名です。

まず、以下のように、出力ファイル用のディレクトリを作成し、データベースをダンプします。

shell> mkdir DUMPDIR
shell> mysqldump --tab=DUMPDIR db_name

次に、DUMPDIR ディレクトリ内のファイルを移動先マシン上の対応するディレクトリに転送し、そのマシン上の MySQL にロードします。

shell> mysqladmin create db_name           # データベース作成
shell> cat DUMPDIR/*.sql | mysql db_name   # テーブル作成
shell> mysqlimport db_name DUMPDIR/*.txt   # load data into tables

また、mysql データベースも忘れずにコピーしてください。このデータベースには、権限テーブル （user、db、host） が格納されているためです。mysql データベースを配置するまでは、移動先のマシン上で MySQL root ユーザとしてコマンドを実行する必要があります。

mysql データベースを移動先のマシンにデータベースをインポートしたら、mysqladmin flush-privileges を実行して、サーバに権限テーブル情報を再ロードさせます。

Windows 上で MySQL をアップグレードする場合は、以下の手順に従って行います。

考えられるエラー状況は以下のとおりです。

A system error has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.

このエラーは、my.cnf ファイル（デフォルトでは C:\my.cnf）に、MySQL が認識できないオプションが含まれていることを示しています。MySQL が my.cnf ファイルを使用しないようにするためにこのファイルの名前を my_cnf.old などに変更して、MySQL を再起動して、これが事実であるかどうかを確認します。事実であることを確認したら、原因となったオプションを特定する必要があります。新しい my.cnf ファイルを作成して、サーバの起動が失敗する原因となるオプションを特定するまで、古いファイルの各パートをそのファイルに移動します（1 つのパートを移動するたびにサーバを再起動します）。

ここでは、Windows 上で MySQL を使用する場合に固有の問題について説明します。

#include <my_global.h>
#include <mysql.h>

glibc に関する以下の注意事項は、MySQL を自分でビルドする場合にのみ適用されます。x86 マシン上で Linux を実行している場合、当社が提供するバイナリを使用する方がはるかに適切です。当社のバイナリは、高負荷なサーバに適したものするために、最適なコンパイラオプションを使用して、当社が考案した最適なパッチ適用済みバージョンの glibc をリンクしています。一般のユーザにとって、多数の同時接続や 2GB の制限を超えるテーブルがある構成であっても、ほとんどの場合、当社のバイナリは最良の選択です。以下のテキストを読んで、どうすべきか判断がつかない場合は、最初に当社のバイナリを試して自社の要件を満たすかどうかを確認し、十分でないことがわかった場合にのみ独自のビルドを検討してください。その場合は、不足な点を当社にお知らせください。次回のバイナリのビルドの際に参考にさせていただきます。

MySQL は、Linux 上で LinuxThreads を使用します。glibc2 が組み込まれていない旧バージョンの Linux を使用している場合は、MySQL をコンパイルする前に LinuxThreads をインストールする必要があります。LinuxThreads は、http://www.mysql.com/downloads/os-linux.html で入手できます。

注意: SMP システム上の Linux 2.2.14 と MySQL で未知の問題が発生したことがあります。SMP システムを使用している場合は、できるだけ速やかに Linux 2.4 にアップグレードすることをお勧めします。これによって、システムの処理速度と安定性が向上します。

注意: バージョン 2.1.1 以前のバージョンの glibc は、INSERT DELAYED ステートメントを発行したときに使用される pthread_mutex_timedwait 処理に重大なバグがあります。glibc をアップグレードするまでは、INSERT DELAYED を使用しないことをお勧めします。

1,000 を超える同時接続を予定している場合は、LinuxThreads にいくつかの変更を加えて再コンパイルし、新しい libpthread.a を MySQL に再リンクする必要があります。 sysdeps/unix/sysv/linux/bits/local_lim.h の PTHREAD_THREADS_MAX を 4096 に増やし、linuxthreads/internals.h の STACK_SIZE を 256 KB に減らしてください。このパスは glibc のルートからの相対パスです。 注意: STACK_SIZE がデフォルト値の 2MB である場合、MySQL は約 600 ? 1,000 接続で不安定になります。

MySQL が十分な数のファイルまたは接続を開けない場合は、その数のファイルを処理するように Linux を設定していない可能性があります。

Linux 2.2 以降では、以下を実行して、割り当てられているファイルハンドルの数をチェックできます。

cat /proc/sys/fs/file-max
cat /proc/sys/fs/dquot-max
cat /proc/sys/fs/super-max

16 MB を超えるメモリがある場合は、init スクリプト（SuSE Linux の /etc/init.d/boot.local など）に以下のような記述を追加してください。

echo 65536 > /proc/sys/fs/file-max
echo 8192 > /proc/sys/fs/dquot-max
echo 1024 > /proc/sys/fs/super-max

root アカウントでコマンドラインから上記のコマンドを実行することもできますが、次回にコンピュータがリブートしたときにそれらの設定は失われます。

あるいは、sysctl ツールを使用して、ブート時に以下のパラメータを設定することもできます。このツールは、多くの Linux ディストリビューションで使用されています（SuSE Linux 8.0 以降、SuSE でもこのツールが追加されています）。/etc/sysctl.conf という名前のファイルに以下の値を入力してください。

# Increase some values for MySQL
fs.file-max = 65536
fs.dquot-max = 8192
fs.super-max = 1024

/etc/my.cnf に以下を追加する必要もあります。

[mysqld_safe]
open-files-limit=8192

これによって、MySQL は最大で 8,192 の接続およびファイルを作成できるようになります。

LinuxThreads の STACK_SIZE 定数は、アドレス空間でのスレッドスタックのスペーシングを制御します。アドレス空間は、個別のスレッドのスタックに十分なスペースを提供できる程度に大きくなければなりませんが、いくつかのスレッドのスタックがグローバルな mysqld データにぶつからない程度に小さくなければなりません。mmap() の Linux 実装は、すでに使用されているアドレスをマップアウトするように指示されると、エラーを返さずに、マップ済みの領域を正常にマップ解除して、ページ全体のデータを消去することが実験でわかっています。mysqld やその他のスレッドアプリケーションの安全性は、スレッドを作成するコードの "紳士的な" 動作にかかっています。ユーザは、任意の時点で稼動しているスレッドの数が、スレッドスタックがグローバルヒープから離れていられる程度に小さくなるようにするための措置をとる必要があります。mysqld では、max_connections 変数に適切な値を設定してこの "紳士的な" 動作を強制する必要があります。

自分で MySQL をビルドする場合、LinuxThreads にパッチを適用する作業をしたくなければ、max_connections を 500 以下の値に設定してください、大きなキーバッファや大きなヒープテーブルなど、mysqld が大量のメモリを割り当てなければならないものがある場合や、2G のパッチが適用された 2.2 カーネルを実行している場合は、さらに小さな値を設定します。当社のバイナリまたは RPM バージョン 3.23.25 以降を使用している場合は、大量のデータを持つキーバッファまたはヒープテーブルがなければ、max_connections を 1500 に設定しても大丈夫です。LinuxThreads の STACK_SIZE の値を小さくすればするほど、スレッドを支障なく作成できるようになります。128K から 256K までの範囲の値を推奨します。

多数の同時接続を使用する場合、fork 爆弾攻撃を避けるために、子プロセスの fork や複製のプロセスにペナルティを科すという、2.2 カーネルの "機能" に悩まされることがあります。これにより、同時実行クライアントの数を増やすと、MySQL がうまくスケールしなくなります。シングル CPU システムでは、スレッド生成が非常に遅くなることでこれが明らかになりました。これは、MySQL に接続するのに長い時間がかかり（1 分程度）、接続を切断するのにも同じだけ時間がかかることを意味します。マルチ CPU システムでは、クライアント数の増加に伴って、クエリ速度が徐々に落ちていくのが観測されました。解決法を見つける過程で、ユーザの 1 人からカーネルパッチを受け取りました。このユーザのサイトではこのパッチが大きな効果を上げているということでした。このパッチは、http://www.mysql.com/Downloads/Patches/linux-fork.patch で入手できます。当社は、開発システムと実稼動システムの両方で、このパッチに非常に広範囲に及ぶテストを実行しました。このパッチは、何の問題も引き起こすことなく MySQL のパフォーマンスを大幅に向上させました。2.2 カーネル上で高負荷のサーバを実行しているユーザに、このパッチをお勧めします。2.4 カーネルではこの問題は修正されています。したがって、システムの現在のパフォーマンスに満足していない場合は、2.2 カーネルにパッチを適用するよりも、2.4 カーネルにアップグレードする方が簡単です。2.4 カーネルは、この公正バグが修正されたほかに、優れた SMP ブーストも提供します。

2 CPU マシンでバージョン 2.4 上の MySQL をテストした結果、MySQL のスケーラビリティが非常に向上することがわかりました。1,000 クライアントに達するまでクエリスループットが低下することは実質的に皆無で、MySQL のスケーリングファクタ（1クライアントでのスループットに対する最大スループットの比率として算出される）は 180% でした。 4 CPU システムでも同様の結果が観察されました。クライアント数が 1,000 に達するまで実質的に速度低下はなく、スケーリングファクタは 300% でした。したがって、高負荷 SMP サーバの場合は、現時点で 2.4 カーネルを使用することを強くお勧めします。最大パフォーマンスを達成するには、2.4 カーネル上で最も高い優先順位を設定して mysqld プロセスを実行することが不可欠であることがわかりました。 これを行うには、renice -20 $$ コマンドを mysqld_safe に追加します。4 CPU マシン上でのテストでは、優先順位を高くすると、400 クライアントでのスループットが 60% 増加しました。

また、現在、当社は、4-way システムおよび 8-wayシステムで 2.4 カーネル上の MySQL のパフォーマンスがどれだけ向上するかについての情報を収集中です。このようなシステムにアクセスでき、何らかのベンチマークを行った場合は、結果を Documentation Team にお送りください。将来、このマニュアルにそれらの結果を記載します。

特に SMP システム上で顕著な、MySQL のパフォーマンスを大きく損なうもう 1 つの問題があります。glibc-2.1 の LinuxThreads の相互排他ロック（mutex）の実装は、短時間だけ相互排他ロックを保持する多数のスレッドを持つプログラムに悪影響を及ぼします。皮肉なことに、SMP システムでは、MySQL を未修正の LinuxThreads にリンクしている場合、多くの場合、マシンからプロセッサを取り外すと MySQL のパフォーマンスが向上します。当社は、この動作を修正するための、glibc 2.1.3 用のパッチを用意しました（http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch）。

MySQL バージョン 3.23.36 は、glibc-2.2.2 のアダプティブロックを使用します。これは、glibc-2.1.3 のパッチ適用済みの相互排他ロックよりもさらに適切です。ただし、状況によって glibc-2.2.2 の現在の相互排他ロックのコードはオーバースピンし、これによって MySQL のパフォーマンスは損なわれるということに注意してください。mysqld プロセスの優先順位を最も高いものに変更することで、この状況が発生する可能性を下げることができます。オーバースピン動作は、パッチで修正することもできました。このパッチは、http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch で入手できます。 このパッチは、オーバースピン、スレッドの最大数、およびスタックスペーシングの修正を一体化したものです。patch -p0 </tmp/linuxthreads-2.2.2.patch の linuxthreads ディレクトリでパッチを適用する必要があります。 glibc-2.2 の将来のリリースに何らかの形でこのパッチが組み込まれることが望まれます。いずれにしても、glibc-2.2.2 にリンクしている場合は、STACK_SIZE と PTHREAD_THREADS_MAX を修正する必要があります。将来、デフォルトが高負荷の MySQL 設定として許容できる値に修正されて、その結果ユーザ自身のビルドが ./configure; make; make install まで減ることが望まれます。

上記のパッチを使用して libpthread.a の静的ライブラリを別にビルドし、MySQL に静的にリンクするためにのみ使用することをお勧めします。これらのパッチが MySQL にとって安全であり、MySQL のパフォーマンスを大幅に向上させることはわかっていますが、その他のアプリケーションについてはわかっていません。その他のアプリケーションをこのライブラリのパッチ適用済みバージョンにリンクする場合や、パッチ適用済みの共有バージョンをビルドしてシステムにインストールする場合は、LinuxThreads に依存するその他のアプリケーションに関してはユーザ自身の責任で行ってください。

MySQL のインストール時に未知の問題が発生した場合や、一般的なユーティリティがハングした場合は、それがライブラリまたはコンパイラに関連するものである可能性が高いです。その場合は、当社のバイナリを使用することでそれらの問題は解決されます。

バイナリディストリビューションの既知の問題の 1 つは libc を使用する旧バージョンの Linux システム（Red Hat 4.x や Slackware など）に関連するもので、ホスト名解決で重大ではない問題がいくつか発生します。 See 項2.6.2.1. 「Linux の注意事項 （バイナリディストリビューション）」。

LinuxThreads を使用している場合は、最小で 3 つのプロセスが稼動しているのが確認されます。これらは、実際はスレッドで、1 つは LinuxThreads マネージャ用のスレッド、1 つは接続を処理するスレッド、1 つはアラームとシグナルを処理するスレッドです。

注意: Linux カーネルと LinuxThreads ライブラリは、デフォルトでは 1,024 のスレッドしか持つことはできません。したがって、パッチ未適用のシステムでは、MySQL への接続は最大で 1,021 しか使用できません。この制限を回避する方法については http://www.volano.com/linuxnotes.html ページを参照してください。

ps で dead 状態の mysqld デーモンプロセスが表示された場合は、通常は、MySQL にバグがあるか、壊れたテーブルがあることを意味します。 See 項A.4.1. 「MySQL が何度もクラッシュする場合に行うこと」。

SIGSEGV シグナルで mysqld が停止した場合に Linux 上でコアダンプを取得するには、--core-file オプションを指定して mysqld を起動します。注意: ulimit -c 1000000 を mysqld_safe に追加するか、--core-file-size=1000000 を指定して mysqld_safe を起動して、コアファイルのサイズを増やします。 See 項4.8.2. 「mysqld_safe（mysqld のラッパ）」。

独自の MySQL クライアントをリンクしているときに、以下のエラーが発生した場合

ld.so.1: ./my: fatal: libmysqlclient.so.4:
open failed: No such file or directory

それらを実行するときに、以下のいずれかの方法で問題を回避できます。

富士通コンパイラ (fcc / FCC) を使用している場合は、MySQL のコンパイルでいくつかの問題が発生します。これは、Linux ヘッダファイルが非常に gcc 指向であるためです。

fcc/FCC を使用する場合は、以下の configure 行が有効です。

CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE \
-DCONST=const -DNO_STRTOLL_PROTO" CXX=FCC CXXFLAGS="-O -K fast -K lib \
-K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE -DCONST=const \
-Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO \
'-D_EXTERN_INLINE=static __inline'" ./configure --prefix=/usr/local/mysql \
--enable-assembler --with-mysqld-ldflags=-all-static --disable-shared \
--with-low-memory

Sorry, the host 'xxxx' could not be looked up

getpwnam: No such file or directory

Syntax error in sched.h. Change _P to __P in the /usr/include/sched.h file.
See the Installation chapter in the Reference Manual.

mysqld.cc -o objs-thread/mysqld.o
mysqld.cc: In function `void init_signals()':
mysqld.cc:315: warning: assignment of negative value `-1' to
`long unsigned int'
mysqld.cc: In function `void * signal_hand(void *)':
mysqld.cc:346: warning: assignment of negative value `-1' to
`long unsigned int'

/usr/lib/libc.a(putc.o): In function `_IO_putc':
putc.o(.text+0x0): multiple definition of `_IO_putc'

shell> CXX=gcc ./configure

CC=ccc CFLAGS="-fast -arch generic" CXX=cxx \
CXXFLAGS="-fast -arch generic -noexceptions -nortti" \
./configure --prefix=/usr/local/mysql --disable-shared \
--with-extra-charsets=complex --enable-thread-safe-client \
--with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared

CFLAGS="-O3 -fomit-frame-pointer" CXX=gcc \
CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors \
-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \
--disable-shared

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-comment=Official MySQL binary" --with-extra-charsets=complex

Solaris では、MySQL ディストリビューションをアンパックする前でも問題が発生することがあります。Solaris tar は長いファイル名を処理できないので、MySQL をアンパックするときに以下のようなエラーが表示されることがあります。

x mysql-3.22.12-beta/bench/Results/ATIS-mysql_odbc-NT_4.0-cmp-db2,\
informix,ms-sql,mysql,oracle,solid,sybase, 0 bytes, 0 tape blocks
tar: directory checksum error

この場合、GNU tar（gtar）を使用して、ディストリビューションをアンパックする必要がありますSolaris 用のプリコンパイル済みコピーは、http://www.mysql.com/downloads/os-solaris.html にあります。

Sun のネイティブスレッドは、Solaris 2.5 以降でのみ機能します。バージョン 2.4 以前の Solaris の場合は、MySQL は自動的に MIT-pthreads を使用します。 See 項2.3.6. 「MIT-pthreads に関する注意事項」。

configure 時に以下のエラーが出力される場合

checking for restartable system calls... configure: error can not run test
programs while cross compiling

このエラーは、コンパイラに問題があることを意味します。 この場合、コンパイラを新しいバージョンにアップグレードする必要があります。config.cache ファイルに以下の行を挿入することで、この問題を解決できることもあります。

ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls='no'}

SPARC 上で Solaris を使用している場合、推奨されるコンパイラは gcc 2.95.2 または 3.2 です。これらのコンパイラは、http://gcc.gnu.org/ にあります。 注意: egcs 1.1.1 および gcc 2.8.1 は、SPARC 上では適正に機能しません。

gcc 2.95.2 を使用している場合は、以下の configure 行を推奨します。

CC=gcc CFLAGS="-O3" \
CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" \
./configure --prefix=/usr/local/mysql --with-low-memory --enable-assembler

UltraSPARC を使用している場合は、"-mcpu=v8 -Wa,-xarch=v8plusa" を CFLAGS および CXXFLAGS に追加することでパフォーマンスを 4% 向上できます。

Sun の Forte 5.0 以降のコンパイラを使用している場合は、configure を以下のように実行できます。

CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt" \
CXX=CC CXXFLAGS="-noex -mt" \
./configure --prefix=/usr/local/mysql --enable-assembler

以下のコンパイルフラグを指定して Sun の Forte コンパイラを使用して、64 ビットのバイナリを作成できます。

CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt -xarch=v9" \
CXX=CC CXXFLAGS="-noex -mt -xarch=v9" ASFLAGS="-xarch=v9" \
./configure --prefix=/usr/local/mysql --enable-assembler

gcc を使用して 64 ビットの Solaris バイナリを作成するには、CFLAGS および CXXFLAGS に -m64 を追加します。注意: これは、MySQL 4.0 以降のみで機能します。MySQL 3.23 にはこれをサポートするために必要な変更が含まれていません。

MySQL ベンチマークでは、UltraSPARC 上で 32 ビットモードで Forte 5.0 を使用した場合、-mcpu フラグを指定して gcc 3.2 を使用した場合と比較して速度が 4% 向上しました。

64 ビットバイナリを作成した場合、32 ビットバイナリよりも速度が 4% 低下しますが、その代わりに mysqld はより多くのスレッドとメモリを処理できます。

fdatasync または sched_yield で問題が発生した場合は、configure 行に LIBS=-lrt を追加することでその問題を修正できます。

以下の段落は、WorkShop 5.3 より前のバージョンのコンパイラにのみ関連するものです。

configure スクリプトを編集して以下の行を変更する必要がある場合もあります。

#if !defined(__STDC__) || __STDC__ != 1

これを次のように変更します。

#if !defined(__STDC__)

-Xc オプションを指定して __STDC__ を有効にすると、Sun のコンパイラは Solaris の pthread.h ヘッダファイルでコンパイルできません。これは Sun のバグです（コンパイラまたはインクルードファイルが壊れています）。

mysqld を実行したときに、以下のようなエラーメッセージが出力された場合は、マルチスレッドオプション（-mt）を有効にしていない Sun のコンパイラを使用して MySQL をコンパイルしようとしています。

libc internal error: _rmutex_unlock: rmutex not held

CFLAGS および CXXFLAGS に -mt を追加して、再実行してください。

SFW バージョンの gcc （Solaris 8 に付属している）を使用している場合は、configure を実行する前に、LD_LIBRARY_PATH 環境変数に /opt/sfw/lib を追加する必要があります。

sunfreeware.com から入手できる gcc を使用している場合は、多くの問題が発生することがあります。問題を回避するためには、gcc および GNU binutils を実行するマシン上で、それらを再コンパイルする必要があります。

gcc を使用して MySQL をコンパイルしているときに以下のエラーが出力された場合は、その gcc が使用している Solaris のバージョン用にコンフィギャされていないことを意味します。

shell> gcc -O3 -g -O2 -DDBUG_OFF  -o thr_alarm ...
./thr_alarm.c: In function `signal_hand':
./thr_alarm.c:556: too many arguments to function `sigwait'

この場合に行うべきことは、最新バージョンの gcc を入手し、現在の gcc コンパイラを使用してそれをコンパイルすることです。少なくとも Solaris 2.5 の場合、gcc のほとんどすべてのバイナリバージョンに古くて利用に適さないインクルードファイルが組み込まれており、それらによって、スレッドを使用するすべてのプログラム（そして、おそらくその他のプログラムも）が破壊されます。

Solaris は、静的バージョンのシステムライブラリ（libpthreads および libdl）は一切提供しません。したがって、--static を指定して MySQL をコンパイルすることはできません。このオプションを指定してコンパイルすると、以下のエラーが表示されます。

ld: fatal: library -ldl: not found

または

undefined reference to `dlopen'

または

cannot find -lrt

多すぎる数のプロセスが非常に迅速に mysqld に接続を試みると、MySQL ログに以下のエラーが出力されます。

Error in accept: Protocol error

この問題を回避するために、--set-variable back_log=50 オプションを指定してサーバを起動してみてください。 注意: --set-variable=name=value 構文および -O name=value 構文は、MySQL 4.0 以降廃止されました。代わりに、--back_log=50 を使用してください。 See 項4.1.1. 「mysqld コマンドラインオプション」。

独自の MySQL クライアントをリンクしている場合、そのクライアントを実行したときに、以下のエラーが発生することがあります。

ld.so.1: ./my: fatal: libmysqlclient.so.#:
open failed: No such file or directory

以下のいずれかの方法でこの問題を回避できます。

configure が -lz でリンクする際に問題が発生し、zlib をインストールしていない場合、以下の 2 つの選択肢があります。

gcc を使用していて、ユーザ定義関数（UDF）を MySQL にロードする際に問題が発生した場合は、その UDF をリンクする行に -lgcc を追加してみてください。

MySQL を自動的に起動させる場合は、/etc/init.d に support-files/mysql.server をコピーして、/etc/rc3.d/S99mysql.server という名前でそのディレクトリへのシンボリックリンクを作成します。

Solaris では setuid() アプリケーションのコアファイルがサポートされていないので、--user オプションを指定している場合、mysqld からコアファイルを取得することはできません。

/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of the previous
definition

#if     !defined(lint) && !defined(__lint)

これを次のように変更します。

#if     !defined(lint) && !defined(__lint) && !defined(getwc)

In file included from mysql.cc:50:
/usr/include/term.h:1060: syntax error before `,'
/usr/include/term.h:1081: syntax error before `;'

CC=gcc CFLAGS="-O3 -fomit-frame-pointer -DHAVE_CURSES_H" \
CXX=gcc \
CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors -fno-exceptions \
-fno-rtti -DHAVE_CURSES_H" \
./configure --prefix=/usr/local/mysql

ここでは、各種の BSD と、それぞれの個別のバージョンについて説明します。

127.0.0.1       localhost localhost.your.domain

CC=gcc CFLAGS="-O2 -fno-strength-reduce" \
CXX=gcc CXXFLAGS="-O2 -fno-rtti -fno-exceptions -felide-constructors \
-fno-strength-reduce" \
./configure --prefix=/usr/local/mysql --enable-assembler
gmake
gmake install
./scripts/mysql_install_db
cd /usr/local/mysql
./bin/mysqld_safe &

shell> rm config.cache
shell> ./configure --with-mit-threads

CFLAGS=-pthread CXXFLAGS=-pthread ./configure --with-mit-threads=no

shell> mysqld_safe --user=mysql --open-files-limit=2048 &

item_func.h: In method `Item_func_ge::Item_func_ge(const Item_func_ge &)':
item_func.h:28: virtual memory exhausted
make[2]: *** [item_func.o] Error 1

shell> env CXX=shlicc++ CC=shlicc2 \
       ./configure \
           --prefix=/usr/local/mysql \
           --localstatedir=/var/mysql \
           --without-perl \
           --with-unix-socket-path=/var/mysql/mysql.sock

shell> env CC=gcc CXX=gcc CXXFLAGS=-O3 \
       ./configure \
           --prefix=/usr/local/mysql \
           --with-unix-socket-path=/var/mysql/mysql.sock

MySQL は、多数のオープンファイルを使用します。そのため、CONFIG.SYS ファイルに以下のような記述を追加する必要があります。

SET EMXOPT=-c -n -h1024

この処理を行わないと、おそらく以下のエラーが発生します。

File 'xxxx' not found (Errcode: 24)

OS/2 Warp 3 で MySQL を使用する場合は、FixPack 29 以降が必要です。OS/2 Warp 4 で MySQL を使用する場合は、FixPack 4 以降が必要です。これは、Pthreads ライブラリの要件です。MySQL は、HPFS、FAT32など、長いファイル名をサポートするパーティションにインストールする必要があります。

INSTALL.CMD スクリプトは、OS/2 の CMD.EXE から実行しなければならず、4OS2.EXE などの置換シェルでは機能しないことがあります。

scripts/mysql-install-db スクリプトは、名前が変更されました。現在、install.cmd と呼ばれているこのスクリプトは、REXX スクリプトで、デフォルトの MySQL セキュリティ設定をセットアップし、MySQL 用の ワークプレイスシェルアイコンを作成します。

動的モジュールサポートは、コンパイルはされていますが、完全にはテストされていません。動的モジュールは、Pthreads ランタイムライブラリを使用してコンパイルする必要があります。

gcc -Zdll -Zmt -Zcrtdll=pthrdrtl -I../include -I../regex -I.. \
    -o example udf_example.cc -L../lib -lmysqlclient udf_example.def
mv example.dll example.udf

注意:OS/2 での制限のために、UDF モジュール名の語幹ステムは 8 文字を超えることはできません。モジュールは、/mysql2/udf ディレクトリに格納されます。safe-mysqld.cmd スクリプトはこのディレクトリを BEGINLIBPATH 環境変数に設定します。UDF モジュールを使用している場合、指定した拡張子は無視されます。拡張子は .udf と仮定されます。 たとえば、Unix では、共有モジュールが example.so という名前の場合、以下のようなコマンドでそこから関数をロードします。

mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "example.so";

OS/2 では、モジュールが example.udf という名前であっても、ユーザはモジュール拡張子を指定しません。

mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "example";

NetWare への MySQL の移植は、Novell 主導で行われた作業です。Novell のユーザは、NetWare 6.5を実行するすべてのサーバに対する自動的な商用ライセンスを備えた MySQL バイナリが、NetWare 6.5 にバンドルされることを歓迎するはずです。

See 項2.1.4. 「NetWare への MySQL のインストール」。

NetWare 用の MySQL は、Metrowerks CodeWarrior for NetWare と特別なクロスコンパイルバージョンの GNU autotool の組み合わせを使用してコンパイルされています。今後、NetWare 用の MySQL をビルドと最適化に関する詳細情報が必要になったら、このセクションをもう一度参照してください。

当社は、過去に MySQL を BeOS に 80% 移植すると語る BeOS の開発者と話したことがありますが、その後連絡はありません。

MySQL は、DBI/DBD クライアントインタフェースという形で Perl をサポートします。See 項11.5. 「MySQL Perl API」。 Perl DBD/DBI クライアントコードは、Perl バージョン 5.004 以降を必要とします。これより前のバージョンの Perl を使用している場合は、このインタフェースは正常に機能しません。

MySQL の Perl モジュールの作成には、MySQL クライアントの開発環境(ヘッダファイルや libmysqlclient ライブラリ)をインストールすることが必要です。 RPM ファイルから MySQL をインストールした場合は、開発環境は MySQL-devel RPM に含まれています。MySQL-devel パッケージをインストールしていることを確認してください。

バージョン 3.22.8 以降、Perl のモジュールはメインのMySQL ディストリビューションとは別に配布されています。Perl モジュールをインストールする場合は、http://www.mysql.com/downloads/api-dbi.html から必要なファイルを入手できます。

Perl モジュールのディストリビューションは、tar 形式の圧縮アーカイブとして提供され、MODULE-VERSION.tar.gz などの名前が付いています。この場合、MODULE はモジュール名で、VERSION はバージョン番号です。Data-Dumper、DBI、DBD-mysql の各ディストリビューションを入手して、この順番でそれらをインストールする必要があります。インストール手順については、以下を参照してください。 ここでは、Data-Dumper モジュールの場合の例で説明しますが、3 つのディストリビューションすべてで手順は同じです。

make test コマンドは、モジュールが正常に機能することを確認するので重要です。注意: DBD-mysql のインストール時にこのコマンドを実行してインタフェースコードを実行する場合は、MySQL サーバが稼動していなければなりません。稼動していないとテストは失敗します。

新しいリリースの MySQL をインストールするときは常に、DBD-mysql ディストリビューションの再ビルドと再インストールを行うことをお勧めします。MySQL をアップグレードした後にすべての DBI スクリプトが失敗するというような現象に気付いた場合は、特に推奨します。

システムディレクトリに Perl モジュールをインストールする権限がない場合や、ローカルの Perl モジュールをインストールする場合は、以下を参照してください。

http://servers.digitaldaze.com/extensions/perl/modules.html#modules

Installing New Modules that Require Locally Installed Modules という見出しの下を調べてください。

Windows では、以下を実行して、ActiveState Perl が組み込まれた MySQL DBD モジュールをインストールする必要があります。

上記のコマンドは、少なくとも ActiveState Perl バージョン 5.6 の場合は有効です。

このコマンドが正常に機能しない場合は、代わりに MyODBC ドライバをインストールして、ODBC を通じて MySQL サーバに接続してください。

use DBI;
$dbh= DBI->connect("DBI:ODBC:$dsn",$user,$password) ||
  die "Got error $DBI::errstr when connecting to $dsn\n";

../mysql/mysql.so モジュールを検出できないというメッセージが Perl から出力された場合は、Perl が共有ライブラリ libmysqlclient.so を見つけることができなかったことを意味します。

この問題は、以下のいずれかの方法で解決できます。

DBD-mysql から以下のエラーが出力された場合は、おそらく gcc を使用しています（または gcc でコンパイルされた古いバイナリを使用しています）。

/usr/bin/perl: can't resolve symbol '__moddi3'
/usr/bin/perl: can't resolve symbol '__divdi3'

mysql.so ライブラリをビルドするときに、リンクコマンドに -L/usr/lib/gcc-lib/... -lgcc を追加します（Perl クライアントをコンパイルするときに、make からの mysql.so に関する出力をチェックしてください）。-L オプションによって、システム内の libgcc.a が配置されているディレクトリのパス名が指定されます。

この問題のもう 1 つの原因は、Perl と MySQL の両方が gcc でコンパイルされていないことです。この場合、両方を gcc でコンパイルすることでこの不一致を解消できます。

テストを実行したときに、DBD-mysql から以下のエラーが出力されることがあります。

t/00base............install_driver(mysql) failed:
Can't load '../blib/arch/auto/DBD/mysql/mysql.so' for module DBD::mysql:
../blib/arch/auto/DBD/mysql/mysql.so: undefined symbol:
uncompress at /usr/lib/perl5/5.00503/i586-linux/DynaLoader.pm line 169.

その場合は、-lz 圧縮ライブラリをリンク行に追加する必要があります。これは、lib/DBD/mysql/Install.pm ファイルの以下の行を変更して行います。

$sysliblist .= " -lm";

この行を以下のように変更します。

$sysliblist .= " -lm -lz";

この後、必ず make realclean を実行して、最初からインストールを行います。

動的リンク（SCO など）をサポートしていないシステム上で Perl モジュールを使用する場合は、DBI と DBD-mysql が組み込まれた静的バージョンの Perl を作成します。これがうまくいく方法は、DBI コードがリンクされた Perl のバージョンを作成して、現在の Perl の上にインストールすることです。次に、それを使用して、DBD コードが追加でリンクされた Perl のバージョンをビルドして、インストールします。

SCO では、以下の環境変数が設定されている必要があります。

shell> LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/progressive/lib
or
shell> LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\
/usr/progressive/lib:/usr/skunk/lib
shell> LIBPATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\
/usr/progressive/lib:/usr/skunk/lib
shell> MANPATH=scohelp:/usr/man:/usr/local1/man:/usr/local/man:\
/usr/skunk/man:

最初に、DBI ディストリビューションが配置されているディレクトリで以下のコマンドを実行して、静的にリンクされた DBI モジュールが組み込まれた Perl を作成します。

shell> perl Makefile.PL -static -config
shell> make
shell> make install
shell> make perl

その後、作成した Perl をインストールする必要があります。make perl の出力に、インストールを行うために実行する必要がある正確な make コマンドが示されます。SCO の場合は、make -f Makefile.aperl inst_perl MAP_TARGET=perl です。

次に、今作成した Perl を使用して、DBD-mysql ディストリビューションが配置されているディレクトリで以下のコマンドを実行して、やはり静的にリンクされた DBD::mysql モジュールが組み込まれた Perl をもう 1 つ作成します。

shell> perl Makefile.PL -static -config
shell> make
shell> make install
shell> make perl

最後に、この新しい Perl をインストールする必要があります。ここでも、make perl の出力に、使用するコマンドが示されます。