最初に決めることは生産 (安定) リリースあるいは開発リリースのどちらにつるかと云うことです。MySQL の開発に於いては、開発の完成度に応じた複数のリリース シリーズがあります。

弊社としては完全にコードが使用できなくなる （凍結） とは想定していません。というのは、これによってバグ出しや修正など必要が対策が出来なくなるからです。「ある程度凍結」 は現在の量産リリースの機能に影響を及ぼさずに小さな修正ができるものを意味しています。当然のことながら、旧バージョンのバグ出しで関連するものはその後のバージョンに反映されています。

お客様が MySQL を最初にお使いになる場合やバイナリの配布のないシステムへのポートをご検討されている場合には、量産シリーズを選択されるようお勧めします。現在の量産シリーズは MySQL 5.0 です。ご利用前にMySQL リリースのすべてを、開発段階のものも含めて、MySQL のベンチマークでチェックし、広範な一連のテストを行うようお願いします。

お客様が旧バージョンを使用していてアップグレードを希望される場合で、シームレスのアップグレードを好まれる場合には、最新バージョンへアップグレードする際には現在お使いのシリーズ（バージョン番号の最後の数字が現在お使いのものより新しいもの）と同じシリーズでアップグレードする必要があります。弊社では致命的なバグの修正および小さな、比較的 「安全な」 変更のみをそのバージョンに行っています。

量産リリースのシリーズで新しい機能の使用を希望される場合には、開発シリーズのバージョンを使用できます。開発シリーズは量産シリーズに比べて安定性に欠けることをご理解きださい。

現在までのすべてのパッチおよびバグ修正を含む最も最新のソースを希望される場合、弊社の BitKeeper レポジトリの中から選択できます。これらは 「リリース版」 ではありませんが、機能ベースのリリースを基にしたコードを試作品を利用できます。

MySQL の命名規則は 3 つの番号に接尾辞を使用しています。例えば、mysql-5.0.12-beta のようになります。リリースの番号の内訳は以下のようになります。

マイナーな更新が行われた場合、最後のバージョン文字列の数字が大きくなります。重要な機能の追加あるいは旧バージョンに互換性のないマイナーな変更が加えられた場合には、バージョン文字列の 2 番目の番号が大きくなります。ファイル フォーマットが変更になった場合、最初の番号の値が増えます。

リリース名にはまたリリースの安定性を示す接尾辞が含まれています。一連の接尾辞のシリーズの進展があった場合のリリースは安定性のレベルの改善の状態を表します。接尾辞には以下のようなものがあります。

MySQL は命名規則を使用していますが、それは殆どの他の製品と多少異なります。一般的には、同じリリースのシリーズに置き換えることなく数週間使用できた場合にはそのバージョンは使用しても通常は安全です。

すべての MySQL のリリースは標準のテストおよびベンチマーク実施して使用に関しては相対的な安全を確認さています。標準のテストは旧バージョンのすべてのバグ修正の経験と事例に基づいていますので、テスト項目とその精度はその都度向上しています。

リリースはすべて最低以下の項目でテストを実施しています。

弊社ではまた最新の MySQL バージョンを社内の生産環境で、最低でも 1 台のマシンで実施しています。100GB 以上のデータで検証しています。

インストールする MySQL を決定したら、次にバイナリの配布にするかソースの配布にするか決める必要があります。殆どの場合、お客様のプラットフォームに適したものがある場合、バイナリの配布を使用することになります。バイナリの配布は多くの Linux の RPM あるいは Mac OS X または Solaris の PKG パッケージ インストーラなど多くのプラットフォームがネイティブのフォーマットで利用できます。配布は Zip アーカイブあるいは圧縮 tar ファイルで利用できます。

バイナリの配布を選択する理由は以下のようになります。

環境によっては、MySQL をソースの配布でインストールしたほうが良い場合もあります。

MySQL の展開は極めて速いため、他の MySQL ユーザーと新しい開発を共有したいと考えています。弊社では他でも必要と思われる新規の有用な機能あればはいつでも新しいリリースを公開していきます。

導入が容易なユーザー要求の新機能についてもユーザーを支援していきます。ライセンス供与を受けたユーザーのご希望、特に弊社がサポートしているお客様のご要望に耳を傾け、それを支援して参ります。

新しいリリースをダウンロードする必要はありません。 ニュース欄をご覧になれば新しいリリースがお客様の仕様にを満たしているか確認できます。付録?C. MySQL Change History 参照。

MySQL の更新は以下の方針に基づいています。

弊社ではバグのないリリースを目指してかなりの時間と労力を費やしています。弊社の方針で MySQL バージョンに既知の致命的な再現性のバグがある場合には量産品をリリースしません。

弊社では設計に関わるすべての一般的な問題、バグ、および懸案事項をすべて文書にまとめています。項B.1.8. 「Known Issues in MySQL」 参照。

弊社では MySQL バージョンの安定性を損なわずに修正可能なバグをすべて修正することを目標にしています。場合によっては、これは安定したバージョン （量産品） ではなく開発バージョンの問題の修正を意味します。当然のことですが、そのような問題をユーザーに認識させるために文書にまとめています。

以下に弊社のビルド プロセスを説明します。

MySQL AB のサービスの一環として、弊社では弊社のサイトでコンパイルしたシステムあるいは MySQL のサポーターのご好意によりサポーターのマシンにアクセスしてコンパイルした MySQL のバイナリを配布しております。

プラットフォームに特化したパッケージ フォーマットのバイナリに加え、弊社では圧縮した tar ファイル (.tar.gz files) のフォームで多数のバイナリ配布を提供しています。.項2.2. 「バイナリの配布を使用した標準 MySQL のインストール」 参照。

弊社のウェブ サイトから入手可能な MySQL のリリースのRPM 配布は 5.1 MySQL AB が作成したものです。

Windows の配布は、項2.3. 「Windows に MySQL をインストールする」 を参照してください。

これらの配布はスクリプト Build-tools/Do-compile を使用して生成したもので、そのスクリプトでソースコードをコンパイルして、scripts/make_binary_distribution を使用して tar.gz アーカイブを作成します。

これらのバイナリは以下のコンパイラーとオプションを使用して設定およびビルドします。これらの情報は各バイナリの tar ファイル配布のスクリプト bin/mysqlbug にある変数 COMP_ENV_INFO および CONFIGURE_LINE をご覧頂くことで取得できます。

以下のいずれかの configure コマンドに最適なオプションをお持ちの方は MySQL internals メーリング リストにメールして頂ければ幸甚です。項1.6.1. 「MySQL メーリング リスト」 参照。

MySQL のデバッグ バージョンのコンパイルを希望される場合、--with-debug あるいは --with-debug=full を以下の configure コマンドに追加して -fomit-frame-pointer オプションを削除します。

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

以下のバイナリは他のユーザーのご好意により MySQL AB に提供されたサード パーティのシステムにビルドされたものです。これらは単なる興味から提出します。MySQL AB はこのシステムを完全に管理していないため、それらにビルドされたバイナリのサポートには限界があります。

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

MySQL パッケージをダウンロードしたら、MD5 チェックサムが MySQL のダウンロード ページのチェックサムを同じであることを確認します。各パッケージには以下おコマンドで検証できるそれぞれのチェックサムがあり、その package_name はお客様がダウンロードするパッケージの名前です。

shell> md5sum package_name

例:

shell> md5sum mysql-standard-5.1.15-beta-linux-i686.tar.gz
aaab65abbec64d5e907dcd41b8699945  mysql-standard-5.1.15-beta-linux-i686.tar.gz

結果おチェックサム (16 桁の数字) が各パッケージの真下のダウンロード ページのチェックサムと一致していることを確認する必要があります。

注:アーカイブ (例えば、.zip あるいは .tar.gz ファイル) のチェックサムでそのアーカイブの中に含まれるファイルのチェックサムでないことを確認します。

すべてのオペレーティング システム md5sum コマンドをサポートしている訳ではないのでその点ご留意ください。中には、単に md5 と呼ばれるものもあり、その他は含まれていまん。Linux の場合、それは GNU Text Utilities パッケージの一部で、様々なプラットフォームに利用できます。ソースコードは http://www.gnu.org/software/textutils/ からもダウンロードできます。OpenSSL の場合には、代わりにコマンド openssl md5 package_name を使用できます。Windows の md5 コマンドライン ユーティリティは http://www.fourmilab.ch/md5/ から入手できます。winMd5Sum はグラフィカルな MD5 チェック ツールで http://www.nullriver.com/index/products/winmd5sum にあります。

パッケージの完全性およびその典拠を確認する別のメソッドとして暗号署名を使用します。このメソッドは MD5 チェックサムを使用するより信頼できますが、手間がかかります。

MySQL AB では、MySQL ダウンロード パッケージを GnuPG (GNU プライバシーガード) で署名しています。GnuPG はオープン ソースで周知の Phil Mimmerman 氏の周知の Pretty Good Privacy (PGP) の代替品です。GnuPG の詳細およびその取得並びにシステムへのインストール方法については http://www.gnupg.org/ を参照してください。殆どの Linux の配布にはデフォルトで GnuPG がインストールされています。GnuPG の詳細は、http://www.openpgp.org/ を参照してください。

特定のパッケージの署名を証明するには、最初に MySQL AB's public GPG ビルド キーを取得する必要があります。それは http://www.keyserver.net/ で入手できます。.取得するキーは build@mysql.com です。また以下のテキストから直接そのキーを切り取り/貼り付けできます。

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 キーリングにインポートするには、gpg --import を使用します。例えば、キーを mysql_pubkey.asc ファイルに保存した場合、インポート コマンドは以下のようになります。

shell> gpg --import mysql_pubkey.asc

ダウンロードして公開ビルド キーをインポートした後、所望の MySQL パッケージと同じくダウンロード ページで入手できるそれに相当する署名をダウンロードします。署名ファイルは配布ファイルの .asc 拡張と同じ名前です。例えば、

両方のファイルが同じディレクトリにあることを確認し、次に以下のコマンドを実行して配布ファイルの署名を証明します。

shell> gpg --verify package_name.asc

例:

shell> gpg --verify mysql-standard-5.1.15-beta-linux-i686.tar.gz.asc
gpg: Signature made Tue 12 Jul 2005 23:35:41 EST using DSA key ID 5072E1F5
gpg: Good signature from "MySQL Package signing key (www.mysql.com) <build@mysql.com>"

Good signature メッセージは署名が証明されたことを意味します。insecure memory が表示された場合無視して構いません。

公開キーの取扱いに関する情報は GPG の資料を参照してください。

RPM には、個別の署名はありません。RPM パッケージには内蔵の GPG 署名および MD5 チェックサムがあります。以下のコマンドを実行してパッケージを検証できます。

shell> rpm --checksig package_name.rpm

例:

shell> rpm --checksig MySQL-server-5.1.15-beta-0.i386.rpm
MySQL-server-5.1.15-beta-0.i386.rpm: md5 gpg OK

注:RPM 4.1 を使用していてそれが次を表示した場合 (GPG) NOT OK (MISSING KEYS:GPG#5072e1f5)、MySQL 公開キー作成のキーをお客様の GPG キーリングにインポートしている場合でも、このキーを最初に RPM キーリングにインポートする必要があります。RPM 4.1 はこの段階でお客様個人の GPG キーリング (あるいは GPG そのもの) を使用しません。むしろ、それはシステム全体のアプリケーションでユーザーの GPG 公開キーリングはユーザー特定のものですのでそれは自身のキーリングとして残ります。MySQL 公開キーを RPM キーリングにインポートするには、以下の説明に従って最初にキーリングを取得します。項2.1.4.2. 「GnuPG を使用した署名確認」.次に rpm --import を使用してそのキーをインポートします。例えば、公開キーをファイル名 mysql_pubkey.asc に保存してある場合、以下おコマンドを使用して公開キーをインポートします。

shell> rpm --import mysql_pubkey.asc

MySQL 公開キーを取得する必要がある場合には、項2.1.4.2. 「GnuPG を使用した署名確認」 を参照してください。

MySQL インストール ウイザードは Microsoft 社の Windows 用に最新のインストール テクノロジを使用した MySQL サーバのインストーラです。MySQL インストール ウイザードと MySQL 設定ウイザードを一緒に用いることによって、ユーザーが MySQL サーバをインストール・設定したら直ぐに使用できます。

MySQL インストール ウイザードは MySQL サーバディストリビューション用の標準にインストーラで、バージョン 4.1.5 およびそれ以降があります。MySQL の以前のバージョンを使用しているユーザーはコンピュータをシャットダウンし、既存の MySQL を手動でアンインストールしてから MySQL を MySQL インストール ウイザードでインストールする必要があります。以前のバージョンからのアップグレードに関する詳細は、項2.3.3.7. 「インストール ウイザードによる MySQL のアップグレード」 を参照してください。

Microsoft 社は Microsoft Windows Installer (MSI) の改善版を Windows の最新機種に使用しています。MSI は Windows 2000、Windows XP、および Windows Server 2003 のアプリケーション インストールの事実上の標準です。MySQL インストール ウイザードはこのテクノロジを活用することでスムーズでさらに柔軟なインストール プロセスを提供しています。

Microsoft Windows インストール エンジンは Windows XP のリリース時に更新されています。旧バージョンの Windows を使用ユーザーは this Microsoft Knowledge Base article をご覧頂ければ最新の Windows インストーラ エンジンへのアップグレード情報を得ることがでます。

さらに、Microsoft 社は最近 WiX (Windows Installer XML) ツールキットをリリースしました。これが Microsoft 社の最初のオープン ソース プロジェクトです。弊社では WiX がオープン ソース で完全な Windows インストール プロセスをスクリプトを使用して柔軟にできるため Wix に切り換えました。

MySQL インストール ウイザードをお客様のようなユーザーのサポートとフェードバックによる改善します。。お客様にとって重要な機能が MySQL インストール ウイザードに欠けている場合、あるいはバグを見つけた場合には、項1.7. 「質問またはバグの報告」 の説明に従ってそれを弊社のバグ データベースまでご連絡お願いします。

MySQL のインストール パッケージは http://dev.mysql.com/downloads/ からダウンロードできます。ダウンロードするパッケージが Zip のアーカイブにある場合には、最初にアーカイブを取り出す必要があります。

ウイザードと起動するプロセスはダウンロードしたインストール パッケージの中身に因ります。setup.exe ファイルがある場合、それをダブル クリックしてインストール プロセスを開始します。.msi ファイルがある場合、それをダブル クリックしてインストール プロセスを開始します。

インストールの方法は 3 種類あります。標準、完全、、およびカスタム の 3 種類です。

標準 のインストールでは MySQL サーバ、mysql コマンドライン クライアント、およびコマンドライン ユーティリティをインストールします。コマンドライン クライアントおよびユーティリティには mysqldump、myisamchk、および MySQL サーバを管理するいくつかのツールが含まれています。

完全 なインストールはインストール パッケージに含まれるすべてのコンポーネントをインストールします。完全なインストールパッケージには埋め込みサーバ ライブラリ、ベンチマーク スイート、サポート スクリプト、および説明書が含まれています。

カスタム のインストールではインスロールするパッケージおよび使用するインストール パスなどを選択できます。詳細およびカスタムのインストールを実施するには、項2.3.3.4. 「カスタムのインストール ダイアログ」 を参照してください。

標準および完全のインストールを選択して Next ボタンをクリックすると、選択の確認画面が表示されインストールを開始します。カスタムのインストールを選択して Next ボタンをクリックすると、項2.3.3.4. 「カスタムのインストール ダイアログ」 で説明したカスタムのインストール ダイアログが表示されます。

MySQL インストール ウイザードに含まれるインストールのパスあるいは特定のコンポーネントを変更する場合には、カスタムインストールを選択します。

カスタム インストール ダイアログの左側のツリー表示に利用できるすべてのコンポーネントが表示されます。インストールしなかったコンポーネントには赤の X アイコン、インストールしたコンポーネントには灰色のアイコンが付きます。インストールするコンポーネントを変更するには、そのコンポーネントのアイコンをクリックし、表示されているドロップダウンリストからインストールするアイコンを選択します。

デフォルトのインストール パスを Change... ボタンをクリックして希望するインストールするパスに変更します。

インストールするコンポーネントとインストール パスを選択したら、Next ボタンをクリックすると選択の確認のダイアログが表示されます。

インストールの種類とオプションのコンポーネントを選択すると、選択確認のダイアログが表示されます。選択を確認するための選択したインストールの種類とインストールのパスがダイアログに表示されます。

選択した設定に間違いない場合、Install ボタンをクリックすると MySQL のインストールが開始されます。設定を変更するには、Back ボタンをクリックします。MySQL をインストールしないで MySQL インストール ウイザードを終了するには、Cancel ボタンをクリックします。

インストールが完了すると、MySQL のウェブサイトに登録するかどうか問われます。登録することによって forums.mysql.com の MySQL フォーラムに投稿したり、バグを bugs.mysql.com にレポートしたり、ニュースレターを購読できます。インストーラの最後の画面ではインストールの概要を表示し、ＭｙSQL 設定ウイザードの起動オプションを提供します。そこで設定ファイルを作成し、 MySQL のサービスをインストールし、セキュリティを設定します。

Install ボタンをクリックすると、MySQL インストール ウイザードがインストールを開始し、次項以降で説明する変更をお客様のシステムに加えます。

レジストリの変更

MySQL インストール ウイザードは標準的なインストールの状況で、HKEY_LOCAL_MACHINE\SOFTWARE\MySQL AB にある Windows レジストリ キーを作成します。

MySQL インストール ウイザードは MySQL Server 5.1 のようなインストールされる主なサーバのバージョン名でキーを作成します。それには 2 つの文字列の値、Location および Version が含まれます。Location 文字列にはインストール ディレクトリへのパスが含まれます。デフォルトのインストールでは C:\Program Files\MySQL\MySQL Server 5.1\ が含まれます。Version 文字列にはリリース番号が含まれます。例えば、MySQL Server 5.1.15-beta のインストールでは、そのキーには 5.1.15-beta の値が含まれます。

これらのレジストリ キーは外部のツールに MySQL サーバのインストール場所を認識させるので、MySQL server のインストール パスを決定するためのハードディスクの完全スキャンをしなくて済みます。レジストリ キーはサーバの起動には必要ありません。MySQL を noinstall Zip アーカイブを使用してインストールすると、レジストリ キーは作成されません。

スタート メニュに戻る

MySQL インストール ウイザードが一般的な MySQL メニューの下にインストールした MySQL の主なバージョンの名前で Windows のスタートメニューに新たにエントリを作成します。例えば、MySQL 5.1 をインストールすると、MySQL インストール ウイザードが MySQL サーバ5.1 の欄を スタートメニューに作成さします。

以下のエントリがスタートメニュー欄に作成されます。

ファイルシステムへの変更

MySQL インストール ウイザードはデフォルトで MySQL 5.1 サーバを C:\Program Files\MySQL\MySQL Server 5.1 にインストールします。そこでは Program Files はお客様のシステムのアプリケーションのデフォルトのロケーションで、5.1 は MySQL サーバの中心となるバージョンです。これが MySQL サーバに推奨しているロケーションで、以前のデフォルトのロケーション C:\mysql を置き換えます。

デフォルトではすべての MySQL アプリケーションは共通のディレクトリ C:\Program Files\MySQL に保持され、Program Files は 客様の Windows にインストールした際のアプリケーション用デフォルトのロケーションです。開発マシンへの標準的なインストールは以下のようになります。

C:\Program Files\MySQL\MySQL Server 5.1
C:\Program Files\MySQL\MySQL Administrator 1.0
C:\Program Files\MySQL\MySQL Query Browser 1.0

これにより MySQL アプリケーションの特定にシステムでの管理と維持が用意になります。

MySQL インストール ウイザードは MSI の機能を使用してサーバのアップグレードを自動的に行います。これにより以前のバージョンを手動でアンインストールすることなく新しいリリースをインストールできます。インストーラーは新しいバージョンをインストールする前に自動的にシャットダウンして以前のバージョンを削除します。

自動アップグレードは同じ大きな枝番と小さな枝番を持つバージョン番号でのインストールの際にのみ利用できます。例えば、MySQL 4.1.5 から MySQL 4.1.6 に自動的にアップグレードできますが、MySQL 5.0 から MySQL 5.1 へのアップグレードはできません。

項2.3.14. 「Windows を使用した MySQL をアップグレードする」 参照。

MySQL 設定ウイザードは Windows 環境でサーバの設定プロセスを自動化します。MySQL 設定ウイザード一連の質問をお客様に問いかけた上ではカスタムの my.iniファイルを作成し、次にお客様の回等をテンプレートに反映してインストールに使用する my.ini ファイルを作成します。

MySQL 設定ウイザードは MySQL 5.1 サーバに含まれており、現在は Windows のユーザーのみ利用できます。

MySQL 設定ウイザードの大部分は MySQL AB に多くのユーザーがここ数年もたらしてくれたフィードバックに結果です。それでも尚、お客様にとって重要な機能が欠けている場合にば、項1.7. 「質問またはバグの報告」 で説明した手順に従ってそれをバグ データベースにレポートお願いします。

MySQL 設定ウイザードは一般的には MySQL インストール ウイザードがインストールされている場合 MySQL インストール ウイザードから起動します。また、MySQL 設定ウイザードを Windows の スタート メニューのＭｙSQL 欄にあるMySQL Server Instance Config Wizard のエントリをクリックすると起動できます。

あるいは、MySQL インストールの bin ディレクトリをナビゲートして MySQLInstanceConfig.exe ファイルのディレクトリから直接起動できます。

MySQL 設定ウイザードが既存の my.ini ファイルを検知した場合、お客様の既存のサーバを再設定するか、あるいは my.ini ファイルを削除してサーバインスタンスを削除し MySQL のサービスを停止して削除します。

既存のサーバを再設定するには、再設定インスタンスオプションを選択して Next ボタンをクリックします。既存の my.ini ファイル名が mytimestamp.ini.bak に変わり、その timestamp が既存の my.ini ファイルが作成された日時です。既存のサーバ インスタンスを削除するには、インスタンスの削除オプションを選択し Next ボタンをクリックします。

インスタンスの削除オプションを選択すると確認ウインドウが表示されます。Execute ボタンをクリックします。MySQL 設定ウイザードが停止して MySQL サービスを削除し、次に my.ini ファイルを削除します。サーバのインストールおよびその data フォルダは削除されません。

再設定インスタンスオプションを選択すると、設定タイプ のダイアログが表示されるので、そこで設定するインストールのタイプを選択します。

MySQL 設定ウイザードを新規の MySQL インストールに起動する、あるいは 再設定インスタンスオプションを既存のインストールに選択すると、設定タイプ のダイアログが表示されます。

選定タイプは 2種類あります。詳細設定 および 標準設定 の 2 種類です。標準設定オプションは新規のユーザーがサーバの設定を変更しないで MySQL を直ぐに起動する場合に適しています。詳細設定オプションは熟練したユーザー用でサーバの設定を細かく設定する場合に適しています。

MySQL を初めて使用されるユーザーで単一ユーザーの開発マシンとしての設定が必要な場合には、標準設定で十分です。標準設定オプションを選択するとサービス オプションおよびセキュリティ オプションを除くすべての設定オプションを MySQL 設定ウイザードが自動的に設定します。

標準設定は既存の MySQL がインストールされている場合にシステムに互換がないオプションを設定します。システムに設定するインストール以外に既存の MySQL をインストールしている場合、詳細設定オプションをお勧めします。

標準設定 を完了するには、それぞれ 項2.3.4.11. 「サービス オプション ダイアログ」 および 項2.3.4.12. 「セキュリティ オプション ダイアログ」 のサービス オプション並びにセキュリティ オプション の項を参照してください。

選択可能な異なる 3 種類のサーバタイプがあります。選択するサーバの種類によって MySQL 設定ウイザードのメモリ、ディスク、および使用しているプロセッサに関する決定に影響を与えます。

データベース利用 ダイアログは MySQL のテーブルを作成する際に使用するストレージ エンジンを表示します。選択したオプションによって InnoDB ストレージ エンジンを利用できるか、何パーセントのサーバ リソースが InnoDB に利用できるかを決定します。

ユーザーの中には InnoDB テーブルスペース ファイルを MySQL サーバのデータディレクトリではなく異なるロケーションに配置することを希望するユーザーもいます。テーブルスペース ファイルの個別のロケーションへの配置はお客様のシステムが高容量あるいは RAID ストレージ エンジンのような高パフォーマンスのストレージ デバイスを利用できる場合に適しています。

InnoDB テーブルスペース ファイルのロケーションを変更するには、ドライブ レターのドロップダウン リストから新しいドライブを選択し、パスのドロップダウン リストから新しいパスを選択します。カスタムのパスを作成するには、 ... ボタンをクリックします。

既存のサーバの設定を変更するには、パスを変更する前に Modify ボタンをクリックします。この状況ではサーバを起動する前に既存のテーブルスペース ファイルを新しいロケーションに手動で移動する必要があります。

サーバのリソースが不足しないようにするために、確立できる MySQL サーバへの同時接続数を制限することが重要です。同時接続ダイアログでサーバの設定を任意に選択し、同時接続数の制限を設定できます。同接続の制限を手動で設定することも出来ます。

ネットワーク オプション ダイアログを使用して TCP/IP ネットワークを有効/無効にし、MySQL サーバの接続に使用するポート番号を設定します。

TCP/IP ネットワークはデフォルトで有効になっています。TCP/IP ネットワークを無効にするには、TCP/IP ネットワーク オプションの隣にあるボックスのチェックを外します。

デフォルトでは Port 3306 を使用しています。MySQL の接続に使用するポートを変更するには、ドロップダウン ボックスから新しいポート番号を選択するか、ドロップダウン ボックスに直接ポート番号を入力します。ポート番号を選択すると、そのポート番号の選択を確認するプロンプトが表示されます。

サーバを SQL モードに設定して厳格モードを有効あるいは無効にします。厳格モード （デフォルト） に設定する MySQL が他のデータベース管理システムと同様の振る舞いをします。アプリケーションを MySQL の旧式の 「許容」 な振る舞いで動作させるには、それらのアプリケーションを使用するかあるいは厳格モードを無効にします。厳格モードの詳細については、項4.2.6. 「SQL モード」 を参照してください。

MySQL サーバは複数の文字セットをサポートしています。オーバーライドを除いてすべてのテーブル、カラム、およびデータベースに適用されるデフォルトのサーバ文字セットに設定できます。MySQL サーバのデフォルトの文字セットを変更するには文字セット のダイアログを使用します。

Windows の NT-ベースのプラットフォームでは、MySQL サーバは Windows のサービスの一貫としてインストールできます。サービスでインストールした場合、MySQL サーバはシステムの起動時に自動的に起動されサービスの不具合時でも Windows を起動すると自動的に再起動します。

MySQL 設定ウイザードがサービス名 MySQL で MySQL サーバをデフォルトでインストールします。このサービスのインストールを望まない場合、Windows のサービスとしてインストールする のオプションの隣にあるボックスのチェックを外します。表示されたドロップダウン ボックスから新しいサービス名を選択するか、ドロップダウン ボックスに新しいサービス名を入力するとサービス名を変更できます。

MySQL サーバをサービスとしてインストールしても起動時の自動的な起動を望まない場合、MySQL サーバを自動的に起動する のオプションの隣にあるボックスのチェックを外します。

root パスワードを MySQL サーバに設定することを強くお勧めします。MySQL 設定ウイザードはデフォルトでその設定を要求します。root パスワードの設定を望まない場合、セキュリティの設定変更 オプションの隣にあるボックスのチェックを外します。

root パスワードを設定するには、任意のパスワードを 新しいルートパスワードおよび確認 のボックスに入力します。既存のサーバを再設定するには、既存の root パスワードを現在のルート パスワード ボックスに入力する必要があります。

ネットワーク上で他の人が root にログインできないようにするには、ルートはローカル ホストのみからアクセス可能 のオプションの隣にあるボックスにチェックを入れます。これにより root アカウントのセキュリティが強化されます。

匿名のユーザーアカウントを作成するには、匿名のアカウントを作成する のオプションの隣にあるボックスにチェックを入れます。匿名のアカウントを作成するとサーバのセキュリティが脆弱になり、ログインおよび許可において困難が伴います。このため、匿名のアカウントはお勧めできません。

MySQL 設定ウイザードの最後のダイアログは 確認ダイアログ です。設定プロセスを実行するには、Execute ボタンをクリックします。前のダイアログに戻るには、Back ボタンをクリックします。MySQL 設定ウイザードをサーバを設定しないで終了するには、Cancel ボタンをクリックします。

Execute ボタンをクリックすると、MySQL 設定ウイザードが一連のタスクを実行しタスクの実行に応じて進捗状況を画面に表示します。

MySQL 設定ウイザードは MySQL の開発者やエンジニアが用意したテンプレートを使用してお客様の選択に基づいて最初に設定ファイル のオプションを決定します。このテンプレート名は my-template.ini でサーバのインストール ディレクトリにあります。

MySQL 設定ウイザードは次にこれらのオプションを my.ini ファイルに書き込みます。my.ini ファイルの最後のロケーションは Write configuration file タスクの隣に表示されます。

MySQL サーバのサービスの作成を選択すと、MySQL 設定ウイザードがサービスを作成して開始します。既存のサービスを再設定すると、MySQL 設定ウイザードがサービスを再起動して設定変更に適用します。

root パスワードの設定を選択すると、MySQL 設定ウイザードがサーバに接続し、新しい root パスワードを設定して選択した他のセキュリティの設定に適用します。

MySQL 設定ウイザードがタスクを完了すると、その概要が表示されます。MySQL 設定ウイザードを終了するには Finish ボタンをクリックします。

MySQL 設定ウイザードが my.ini ファイルを MySQL サーバのインストール ディレクトリに配置します。これにより設定ファイルを特定のサーバインスタンスに関連付けます。

MySQL サーバの my.ini ファイルのロケーションの確認に、このファイル名に類似した引数をサービス インストールの一貫として MySQL サーバに渡します。

--defaults-file="C:\Program Files\MySQL\MySQL Server 5.1\my.ini"

ここでは、C:\Program Files\MySQL\MySQL Server 5.1 が MySQL サーバへのインストール パスに置き換えられます。--defaults-file オプションが起動時に MySQL サーバに設定オプションに指定したファイルを読み込ませます。

my.ini ファイルを変更するには、そのファイルをテキスト エディタで開いて必要な変更を加えます。サーバの設定も MySQL Administrator ユーティティで変更できます。

mysql および mysqldump コマンドラインクライアントなどの MySQL クライアントおよびユーティリティはサーバのインストール ディレクトリにある my.ini ファイルのを見つけることはできません。クライアントおよびユーティリティのアプリケーションを設定するには、新しい my.ini ファイルを C:\WINDOWS あるいは C:\WINNT ディレクトリ (お客様の Windows のバージョンに適したいずれか) に作成します。

MySQL をビルドするには以下の手順に従います。

ビルドしたプログラムが正常に機能していることに満足したら、サーバを停止します。この段階でディストリビューションをインストールできます。インストールを行う一つの方法として MySQL のソース ディストリビューションの scripts ディレクトリにある make_win_bin_dist スクリプトを使用する方法があります (項4.5.1. 「make_win_bin_dist ? Package MySQL 配布 (ZIP アーカイブ)」 参照)これはシェル スクリプトですので、これを使用する際は Cygwin をインストールする必要があります。それによりビルドした実行ファイルの Zip アーカイブを作成し、 MySQL をインストールするロケーションに解凍するファイルをサポートします。

ディレクトリやファイルを直接コピーして MySQL をインストールすることもできます。

インストールしたら、バイナリの Windows ディストリビューションと同じようにサーバを設定して起動します。項2.3. 「Windows に MySQL をインストールする」 参照。

MySQL Windows のソースを Borland C++ 5.02 でコンパイルできます。(Windows のソースはMicrosoft VC++ 用のプロジェクトしか含んでいないため、Borland C++ の場合にはご自身でプロジェクトファイルを作成する必要があります。

Borland C++ の既知の問題の一つは、VC++ とは構成の配列が異なっていることです。このとは、デフォルトの libmysql.dll ライブラリ （VCC++ でコンパイルした） を Borland C++ に使用すると問題が発生するということを意味します。この問題を避けるには、mysql_init() を NULL で引数としてコールするだけで、事前に割り当てられた MYSQL 構成としてコールしないことです。

mysql_install_db スクリプトの目的は新しい MySQL 権限テーブルを生成することです。それは既存の MySQL 権限テーブルを上書きしないので、他のデータに影響を及ぼすことはありません。

権限のテーブルを再度作成するには、稼動している mysqld サーバを停止します。次にデータ ディレクトリの mysql ディレクトリの名前を変更して保存し、次に mysql_install_db を実行します。.お客様の現在のディレクトリが MySQL のインストール ディレクトリで mysql_install_db が bin ディレクトリにあり、データ ディレクトリ名が data のであるとします。mysql データベースの名前を変更し mysql_install_db を実行するには、以下のコマンドを使用します。

shell> mv data/mysql data/mysql.old
shell> bin/mysql_install_db --user=mysql

mysql_install_db を実行すると、以下の問題が発生する場合があります。

MySQL で提供された mysql_install_db スクリプトを実行する幾つかの代案があります。

一般的には mysqld サーバを以下のいずれかで起動します。

mysqld_safe および mysql.server スクリプト並びに Mac OS X 起動アイテムでシステムの起動時にサーバを手動、あるいは自動的に起動できます。mysql.server および起動アイテムはサーバを停止することもできます。

mysql.server スクリプトを使用してサーバを手動で起動・停止するには、サーバを start あるいは stop 引数で呼び出します。

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

mysql.server がサーバを起動する前に、ロケーションを MySQL インストール ディレクトリに変更し、次に mysqld_safe を実行します。サーバを特定のユーザーとして起動するには、適切な user オプションを/etc/my.cnf オプション ファイルの [mysqld] グループにこの項の後で示すように追加します。(バイナリ ディストリビューションの MySQL を標準と異なるロケーションにインストールした場合には mysql.server の編集が必要になる場合があります。mysqld_safe を実行する前にそれを cd に変更して適切なディレクトリに入れます。これを行うと、変更したバージョンの mysql.server は将来 MySQL をアップグレードすると上書きされる場合がありますので、編集したバージョンをインストールできるようにコピーを取っておく必要があります。

mysql.server stop は停止する信号を送ってサーバを停止します。mysqladmin shutdown を実行してサーバを手動で停止することもできます。

サーバ上の MySQL を自動的に起動・停止するには、起動・停止コマンドを /etc/rc* ファイルの適切な場所に加える必要があります。

Linux サーバ RPM パッケージ (MySQL-server-VERSION.rpm) を使用する場合には、mysql.server スクリプトを /etc/init.d ディレクトリに mysql の名前でインストールします。それを手動でインストールする必要はありません。Linux RPM パッケージに関する詳細は、項2.4. 「Linux に MySQL をインストールする」 を参照してください。

ベンダーによっては起動スクリプトをインストールする RPM パッケージを mysqld のような別名で提供している場合もあります。

MySQL をソース ディストリビューションからあるいは mysql.server を自動的にインストールしないバイナリのディストリビューション フォーマットを使用してインストールする場合、それを手動でインストールできます。そのスクリプトは MySQL インストール ディレクトリの support-files ディレクトリあるいは MySQL のソース ツリーにあります。

mysql.server を手動でインストールするには、それを /etc/init.d ディレクトリに mysql の名前でコピーし、次にそれを実行ファイルにします。実行ファイルにするには mysql.server を格納を格納しこれらのコマンドを実行する適切なディレクトリにロケーションを変更します。

shell> cp mysql.server /etc/init.d/mysql
shell> chmod +x /etc/init.d/mysql

古い Red Hat システムは /etc/init.d ではなく /etc/rc.d/init.d ディレクトリを使用しています。上記のコマンドを状況に応にて変更します。または、最初に /etc/init.d をシンボリック リンクとして /etc/rc.d/init.d にポイントして作成します。

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

スクリプトをインストールした後、使用しているオペレーティング システムに基づいてシステムの起動時にコマンドを実行できるように有効化します。Linux では、chkconfig を使用します。

shell> chkconfig --add mysql

Linux システムに中には、mysql スクリプトをフルに有効にするには以下のコマンドが必要になる場合があります。

shell> chkconfig --level 345 mysql on

FreeBSD では、起動スクリプトは通常 /usr/local/etc/rc.d/ にあります。.rc(8) のマニュアルではこのディレクトリのスクリプトはそれらのベースの名前が *.sh シェルのファイル名のパターンに一致したときのみ実行できると書いてあります。そのディレクトリの他のファイルあるいはディレクトリは無視されます。換言すれば、FreeBSD では、mysql.server スクリプトを /usr/local/etc/rc.d/mysql.server.sh としてインストールして自動による起動を有効にします。

上記の設定の代案として、オペレーティング システムの中には /etc/rc.local あるいは /etc/init.d/boot.local を使用して起動時に追加のサービスを起動しています。この方法で MySQL を起動するには、以下のようなコマンドを適切な起動ファイルに追加します。

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

他のシステムの起動スクリプトのインストール方法についてはそのオペレーティング システムの説明書をお読みください。

mysql.server のグローバル /etc/my.cnf ファイルにオプションを追加できます。一般的な /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 スクリプトは以下のオプションを実行します。basedir、datadir、および pid-file。指定する場合には、それらはコマンドラインではなくオプション ファイルに入れる 必要が あります。 mysql.server は start および stop をコマンドラインの引数として理解します。

以下のテーブルはどのオプション グループからサーバおよび各起動スクリプトがオプション ファイルを読むか示しています。

[mysqld-major_version] は[mysqld-5.0] および [mysqld-5.1] の名前のグループが 5.0.x、5.1.x、などのバージョンのサーバによって読まれることを意味しています。この機能は所定のリリース シリーズのサーバによってのみ読まれるオプションを指定するために使用されています。

下位互換の場合、mysql.server は[mysql_server] グループも読み込み mysqld_safe は[safe_mysqld] グループも読み込みます。しかし、MySQL 5.1 を使用する際は、[mysql.server] および [mysqld_safe] グループを読み込めるようにオプション ファイルをアップグレードする必要があります。

項3.3.2. 「オプションファイルの使用」 を参照してください。

この項では Unix 上のサーバ起動時の問題に関するトラブルシューティングについて説明します。Windows を使用している場合には、項2.3.13. 「Windows への MySQL インストールにおけるトラブルシューティング」 を参照してください。

サーバの起動時に問題がある場合、以下を試してみます。

ストレージ エンジンにその振る舞いを管理するオプションが付いているものもあります。my.cnf ファイルを作成して使用するエンジンの起動オプションを指定します。トランザクション テーブル (InnoDB、NDB) をサポートするストレージ エンジンを使用する場合には、サーバを起動する前にそれらが所定の設定になっているか確認します。

MySQL Enterprise お客様の環境に適した起動オプションに関する専門家の助言が必要な場合には、MySQL ネットワーク モニタリングおよびアドバイザリ サービスのご購読をお勧めします。詳細は、http://www.mysql.com/products/enterprise/advisors.html を参照してください。

ストレージ エンジンは特に指定しない場合はデフォルトの値を使用します。しかし、デフォルトの値が必ずしも適切であるとは限らないので利用できるオプションを確認して明示的に値を指定することをお勧めします。

mysqld サーバが起動すると、ロケーションをデータ ディレクトリに変更します。そこでデータベースを探し、ログ ファイルを書き込みます。サーバはデータ ディレクトリで pid (プロセス ID) ファイルも書き込みます。

サーバをコンパイルするとデータ ディレクトリのロケーションが組み込まれます。ここがデフォルトでサーバがデータ ディレクトリを探す場所です。データ ディレクトリがシステムのどこか別の場所にある場合には、サーバは正常に動作しません。mysqld を --verbose および --help オプションを実行してデフォルトのパスの設定を決定できます。

システム上のデフォルトのロケーションが MySQL のインストール レイアウトと一致しない場合、オプションをコマンドラインあるいはオプション ファイルのmysqld あるいは mysqld_safe に指定してそれらをオーバーライドできます。

データ ディレクトリのロケーションを明示的に指定するには、--datadir オプションを使用します。しかし、通常は MySQL をインストールしそこでデータ ディレクトリを探すベース ディレクトリのロケーションを mysqld に指定できます。--basedir オプションで指定できます。

パス オプションの指定の結果を知るには、mysqld をそれらのオプションで実行し次に--verbose および --help オプションを実行します。例えば、ロケーションを mysqld をインストールしたディレクトリに変更して次に以下のコマンドを実行すると、その結果 /usr/local のベース ディレクトリでサーバが起動します。

shell> ./mysqld --basedir=/usr/local --verbose --help

--datadir のようなオプションも同様に指定できますが、--verbose および --help は最後のオプションになります。

任意のパスを設定した後、サーバを--verbose および --help を使用しないで起動します。

mysqld が動作している時に、以下のコマンドを実行してどのパス設定が使用されているか確認できます。

shell> mysqladmin variables

または

shell> mysqladmin -h host_name variables

host_name は MySQL サーバのホスト名です。

mysqld を実行したときに Errcode 13 (Permission denied を意味する) が表示された場合は、データ ディレクトリの権限あるいはそのコンテンツがサーバのアクセスを許可していないことを意味します。この場合、関連するファイルおよびディレクトリの権限を変更してサーバがそれらのを使用できるようにします。サーバを root からも起動できますが、この場合セキュリティが脆弱になるためこの立ち上げは避けるべきです。

Unix では、ロケーションをデータ ディレクトリに変更してデータ ディレクトリおよびそのコンテンツの所有者権限をチェックし、サーバにアクセス権があるか確認します。例えば、データ ディレクトリが /usr/local/mysql/var の場合は、以下のコマンドを使用します。

shell> ls -la /usr/local/mysql/var

データ ディレクトリあるいはそのファイルまたはサブディレクトリがサーバを運用するためのログイン アカウントの所有でない場合、それらの所有者権限をそのアカウントに変更します。そのアカウントが mysql の場合、以下のコマンドを使用します。

shell> chown -R mysql /usr/local/mysql/var
shell> chgrp -R mysql /usr/local/mysql/var

サーバが正常に起動できない場合、エラーログをチェックします。ログ ファイルはデータ ディレクトリ (一般的には Windows ではC:\Program Files\MySQL\MySQL Server 5.1\data、Unix のバイナリ ディストリビューションでは /usr/local/mysql/data、Unix ソース ディストリビューションでは /usr/local/var) にあります。データ ディレクトリの host_name.err および host_name.log のフォーム名のファイルは、host_name はサーバのホスト名です。次にこれらのファイルの最後の数行を調べます。Unix では、それらの表示に tail を使用します。

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

エラーログにはサーバが起動しなかった情報が含まれています。

以下のいずれかのエラーが発生した場合、他のプログラム （多分別の mysqld サーバ) が mysqld が使用する TCP/IP ポートあるいはUnix のソケット ファイルを使用していることを意味します。

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

別の mysqld サーバを動作している場合には、ps を使用します。その場合、mysqld を再度起動する前にサーバをシャットダウンします。(別のサーバの動作中に、複数のサーバを稼動させる運用の仕方に関する情報は、項4.12. 「同じマシン上での複数 MySQL サーバの実行」 にあります。)

サーバがどれも動作していない場合、コマンド telnet your_host_name tcp_ip_port_number を実行してみます。(デフォルトの MySQL ポート番号は 3306 です。)次に Enter を数回押します。次のようなエラーメッセージが表示されなかった場合 telnet:Unable to connect to remote host:Connection refused、mysqld が使用しようとしている TCP/IP ポートを他のプログラムが使用しています。その際どのプログラムが使用しているかを調べてそれを無効にするか、または mysqld に --port オプションで別のポートを指定します。この場合、サーバに TCP/IP 経由で接続する際にクライアント プログラムにポート番号を指定する必要があります。

ポートが接続できない別のの理由にファイアウォールがその接続をブロックしている場合があります。その場合、ファイアウォールの設定をポートにアクセスできるように変更します。

サーバが起動しても接続できない場合、以下のようなエントリが /etc/hosts ないか確認します。

127.0.0.1       localhost

この問題は実行中のスレッド ライブラリがないシステムで MIT-pthreads を使用する設定が必要な MySQL でのみ発生します。

mysqld を起動できない場合、トレース ファイルを作成し --debug オプションを使用して問題を探します。Creating Trace Files 参照。

MySQL には最低でも Linux バージョン 2.0 が必要です。

警告: 弊社では予想外の問題が Linux 2.2.14 および SMP システムの MySQL で報告されています。弊社にはまた MySQL のユーザーから MySQL を kernel 2.2.14 で使用した場合深刻な安定性の問題が発生するとの報告も寄せられています。この kernel を使用している場合にば、2.2.19 (あるいはそれ以降) あるいは 2.4 kernel にアップグレードする必要があります。複数の CPU ボックスを使用している場合には、2.4 のご使用を真剣にご検討ください。2.4 は速度を大幅に改善します。お客様のシステムがさらに安定します。

LinuxThread を使用する際は、少なくとも 3 種類の mysqld プロセスを実施する必要があります。これらは ファクト スレッドにあります。1 つ目は LinuxThread マネージャ用、2 つ目接続用、3 つ目はアラームおよび信号を扱います。

MySQL の Linux-Intel バイナリおよび RPM リリースは最高速度に設定されています。弊社では常に高速で安定したコンパイラの使用を心がけています。

バイナリのリリースは -static とリンクしていますので、通常はどのバージョンのシステム ライブラリを使用しているのか心配する必要はありません。Linux Thread をインストールする必要もありません。-static とリンクしたプログラムは動的にリンクしたプログラムより少しだけ大きくなりますが、多少速く (3-5%) なっています。しかし、静的にリンクされたプログラムの一つの問題は、ユーザー定義関数 （UDF) を使用できないことです。UDF を書いたり使用する （C あるいは C++ プログラマーの場合のみ) 場合、動的リンクを使用してご自身で MySQL をコンパイルする必要があります。

バイナリ ディストリビューションの既知の問題は libc (Red Hat 4.x あるいは Slackware など) を使用した旧 Linux システムでは、ホスト名のリゾリューションに幾つかの (致命的ではない) 問題があることです。お客様のシステムが glibc2 ではなく libc を使用している場合、多分ホスト名リゾリューションおよび getpwnam() で問題に遭遇します。これは glibc (不幸にも) が、-static でコンパイルする時でさえ、いくつかの外部のライブラリに依存してホスト名リゾリューションおよび getpwent() を実装しているからです。これらの問題は 2 つの方法で明らかです。

別の解決策、それは両方の問題を解決しますが、バイナリのディストリビューションを使用しません。MySQL のソース ディストリビューション (RPM あるいは tar.gz フォーマットで) を取得しそれをインストールします。

Linux 2.2 バージョンの中には、クライアントが TCP/IP でmysqld サーバへ新たに相当数の接続をしたときに Resource temporarily unavailable のエラーが表示される場合があります。この問題は Linux には TCP/IP ソケットを閉じる時間とシステムが実際のそれを開放する間に遅延があるためです。TCP/IP のスロット数には限りがあるため、クライアントが余りにも多くの TCP/IP 接続を短時間に行うとリソース不足のエラーに遭遇します。例えば、MySQL test-connect ベンチマークを TCP/IP で実行する時にエラーが発生する場合があります。

弊社ではこの問題に関して Linux の別々のメーリング リストを使用して数回連絡を取っていますが現在までのところまだ解決策は見つかっておりません。唯一これまで分かっている 「fix」 はクライアントの接続を執拗に続けること、あるいはデータベース サーバとクライアントが同じマシンで稼動している場合、TCP/IP 接続ではなく Unix のソケット ファイル接続を使用することです。

以下の glibc に関する注釈は MySQL をご自身でビルドする際にのみ適用します。Linux を x86 マシンで使用している場合、弊社のバイナリが多くのケースで最適です。弊社では弊社のバイナリを弊社が知り得る限りベスト パッチの glibc バージョンにリンクし最高のコンパイラ オプションを使用して、高負荷のサーバに最適なソリューションを目指しています。一般的なユーザーにとって、多数の同時接続あるいは 2 GB の制限を越えるテーブルでの設定においてさえ、弊社のバイナリはその殆どのケースで最適な選択といます。以下のテキストを読まれた後で、それでも何をすべきか分からない場合には、まず弊社のバイナリを試してみてお客様のニーズに合うか決めてください。もし要求を十分満たすことができない場合には、ご自身でビルドしてみることもできます。そのような場合、お客様のご意見を寄せて頂ければ弊社はさらによいバイナリをビルドするための参考にさせて頂きます。

MySQL は Linux に LinuxThread を使用しています。glibc2 を実装していない旧 Linux バージョンを使用している場合には、MySQL をコンパイルする前に LinuxThread をインストールする必要があります。LinuxThread は http://dev.mysql.com/downloads/os-linux.html で取得できます。

INSERT DELAYD ステートメントが発行される時に使用されるバージョン 2.1.1 を含む以前のglibc のバージョンには pthread_mutex_timedwait() の処理で致命的なバグがあります。glibc をアップグレードするまでは INSERT DELAYED を使用しないようお勧めします。

Linux kernel および LinuxThread ライブラリはデフォルトで最大 1,024 スレッドを扱うことができます。1,000 以上の同時接続を計画している場合には、以下のように LinuxThread を変更する必要があります。

LinuxThreads のスレッド制限の回避法の詳細は http://www.volano.com/linuxnotes.html にあります。

MySQL のパフォーマンスに大きな影響を与える別の問題が、特に SMP システム上であります。glibc 2.1 の LinuxThreads の mutex の実装が mutex をほんの短時間保持する多くのスレッドを使用するプログラムで非常に貧弱です。これにより逆説的な結果が生じます。MySQL を無修正の LinuxThreads にリンクさせる際、SMP からプロセッサを削除すると MySQL パフォーマンスが実質的に多くのケースで改善されます。弊社ではこの振る舞いを修正するためのパッチを glibc 2.1.3 に用意しましたhttp://dev.mysql.com/Downloads/Linux/linuxthreads-2.1-patch)。

glibc 2.2.2 を使用する際、MySQL に adaptive の mutex を使用することによって glibc 2.1.3 にパッチ版を使用するよりはるかによくなります。しかし、使用条件によっては、glibc 2.2.2 の現在の mutex code はオーバースピンし、MySQL パフォーマンスを低下さるので、その点注意が必要です。この現象の再現を mysqld のプロセスを最高度まで再調整することで減らすことができます。弊社ではまたパッチを使用してオーバースピンを修正できるようにしました。そのパッチは http://dev.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch にあります。そのパッチでオーバースピン、スレッドの最大数、およびスタックのスペースをすべて一つにまとめるなどの修正を加えています。そのパッチは linuxthreads ディレクトリに patch -p0 </tmp/linuxthreads-2.2.2.patch を適用します。弊社ではそのパッチが glibc 2.2 の今後のリリースに反映されることを希望しています。いずれにしろ、glibc 2.2.2 にリンクするには、STACK_SIZE および PTHREAD_THREADS_MAX をまだ修正する必要があります。弊社ではデフォルトの値が、今後 MySQL の高負荷設定に対応できるように修正され、お客様ご自身でビルドする際に必要なコマンドが ./configure; make; make install まで減少できるように期待しています。

これらのパッチは特定の libpthread.a の静的バージョンのビルドに使用し、MySQL に静的にリンクする際にのみ使用することをお勧めします。これらのパッチは MySQL に使用する際は安全でそのパフォーマンスを大幅に改善しますが、他のアプリケーションに対する影響についてはなにも言う立場にありません。LinuxThreads をライブラリのパッチ版の静的ベージョンが必要な他のアプリケーションにリンクする、あるいはパッチ共有バージョンをビルドしそれをお客様のシステムにインストールすることは、お客様ご自身のリスクで行うことになります。

MySQL のインストールの最中に予想外の問題に遭遇した場合、あるいはそれに一般的なユーティリティのハンギングが伴う場合、それらの問題はライブラリあるいはコンパイラにいずれかに起因するものである確立が高いといえます。このような場合には、弊社のバイナリがその問題を解決します。

お客様ご自身の MySQL クライアント プログラムをリンクさせる場合、ランタイムで以下のエラーが表示される場合があります。

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

この問題は以下のメソッドのいずれかで回避できます。

富士通のコンパイラ (fcc/FCC) を使用する場合、Linux のヘッダーファイルは gcc に特化したものですので MySQL のコンパイルで問題が発生する場合があります。以下の configure 行が fcc/FCC の役に立つはずです。

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

mysql.server はMySQL インストール ディレクトリの support-files ディレクトリあるいは MySQL のソース ツリーにあります。それを自動的起動・シャットダウンの /etc/init.d/mysql としてインストールします。項2.10.2.2. 「MySQL を自動的に起動・停止する」 参照。

MySQL が十分なファイルや接続ができない場合、十分なファイルを処理する Linux を設定していない場合があります。

Linux 2.2 およびそれ以降では、割り当てられたファイル処理を以下のようにチェックできます。

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

16MB 以上のメモリがある場合、何か以下のようなものを 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

コマンドラインの echo コマンドを root として実行することもできます。しかし、これらの設定は次回コンピュータを再起動した時には失われます。

代わりに、これらのパラメータを sysctl ツールを使用して起動時に設定できます。それは多くの Linux ディストリビューション （SuSE Linux 8.0 およびそれ以降を含む) で使用されています。以下の値を /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

これによりサーバの接続総数およびオープン ファイルの上限 8,192 まで可能になります。.

LinuxThreads の STACK_SIZE 定数によりアドレス スペースのスレッド スタックのスペースを管理します。その管理は各スレッド スタックに十分余裕をあたえられるように大きく、しかしスレッドのスタックが mysqld データに入り込まないように小さくなくてはなりません。幸いなことに、現在使用しているアドレスのマップを外す要求を出した場合 Linux の mmap() の実装によってマップした領域のマップを外し、エラーを返さずにページ全体のデータをゼロにすことが弊社の実験で分かりました。ですから mysqld あるいは他のスレッド アプリケーションの安全はスレッドを作成するコードの 「紳士的な」 振る舞いにかかっています。ユーザーは所定の時間での実行中のスレッド数がスレッド スタックがグローバル ヒープに近寄らないように十分に低くなっているようにするための対策を講じる必要があります。mysqld を使用して、適切な値を max_connections 変数に設定することでこの振る舞いを強化する必要があります。

MySQL をご自身でビルドする場合、スタックをよくするために LinuxThreads をパッチします。項2.13.1.3. 「Linux バイナリ ディストリビューションの注釈」 参照。LinuxThreads のパッチを望まない場合、max_connections を 500 以下の値に設定します。その値は大きなキーバッファ、大きなヒープ テーブル、あるいは mysqld に大きな容量のメモリを割り当てる何かがある、または 2.2 kernel を 2GB パッチで動作させる場合にはもっと小さい値にする必要があるかも知れません。弊社のバイナリあるいは RPM バージョンを使用する場合、大きなキーバッファあるいは多量のデータを伴う大きなヒープ テーブルがない場合、max_connections が 1500 に設定しても安全です。LinuxThreads のSTACK_SIZE が小さければ小さいほど、多くのスレッドを安全に作成できます。弊社では 128KB から 256KB の間の値をお勧めしています。

多数の同時接続を使用する場合、フォーキングあるいは子のクローン化でプロセスを妨げることによってフォーク ボム アタックを妨げようとする 2.2 kernel の「feature」 によって影響を受ける場合があります。これによって 同時クライアントが増えるに従って MySQL はうまくスケールできなくなります。シングルの CPU を使用したシステムで、この例を非常に遅いスレッドで経験しました。MySQL に接続するのに長い時間 (1 分近く）がかかる場合があり、まさにそれをシャットダウンするほどの時間がかかります。1 台の複数の CPU を使用したシステムでは、クライアント数が増えるに従ってクエリの速度が徐々に遅くなっていきました。解決策を探す段階で、弊社のユーザーの 1 社からユーザーのサイトで効果があったとのことで kernel のパッチが届けられました。このパッチは http://dev.mysql.com/Downloads/Patches/linux-fork.patch で利用できます。.弊社ではこのパッチに弊社の開発や実際の生産システムを含む広範なテストを実施しました。そのパッチは何ら問題なく MySQL のパフォーマンスを大幅に改善しましたので、弊社では高負荷のサーバを 2.2 kernel で運用している弊社のユーザーに推薦しました。

この問題は 2.4 kernel では修正されているため、現在稼働中のシステムのパフォーマンスに満足しされていない場合には 2.2 のパッチ版よりはむしろ、2.4 へのアップグレードするほうが容易です。SMP システムでは、アップグレードすることによって既知のバグの修正に加えて SMP のブーストがよくなります。

弊社では MySQL を 2.4 kernel で 2 つの CPU を搭載したマシンでテストしましたが MySQL スケールが 大幅に 良くなっています。1,000 クライアントまでのテストを実施している間に実質的にクエリの減速がなく、MySQL スケーリング　ファクターは (最大のスループットと 1 台のクライアント スループットの比率を計算したもの) は 180% でした。.CPU を 4 つ搭載したシステムでも同様の結果が得られました。クライアント数を 1,000 まで増やしても実質的な減速がなく、スケーリング ファクターは 300% でした。これらの結果に基づいて、2.2 kernel を使用した高負荷の SMP サーバには、弊社でこの段階で 2.4 kernel にアップグレードするよう強くお勧めします。

最高のパフォーマンスを実現するには最優先課題として mysqld を 2.4 kernel で動作させることが必須であるということが分かりました。これを行うには renice -20 $$ コマンドを mysqld_safe に追加します。4 CPU 搭載マシン上での弊社のテストでは、その優先度を上げることによって 400 クライアントまでの増加の間に 60% の結果が出ました。

弊社では現在 2.4 kernel を four-way および eight-way のシステムで使用した場合 MySQL の性能がどのように良くなるか情報を集めています。お客様がその様なシステムにアクセスして何かベンチマークを行った場合、その結果を <benchmarks@mysql.com> まで　Eメール頂ければ幸甚です。.弊社ではそれを検討してマニュアルに追加するかどうかを検討します。

ps で mysql サーバプロセスがデッドした場合、これは通常 MySQL にバグがあるかあるいはテーブルが破損していることを意味します。項B.1.4.2. 「What to Do If MySQL Keeps Crashing」 参照。

mysqld が SIGSEGV 信号でデッドした場合に Linux でコア ダンプを取得するには、mysqld を --core-file オプションで起動します。多分コア ファイルのサイズを ulimit -c 1000000 を mysqld_safe に追加あるいは mysqld_safe を --core-file-size=1000000 で起動して増やす必要があります。.項4.3.1. 「mysqld_safe ? MySQL サーバ スタートアップ スクリプト」 参照。

MySQL には libc 5.4.12 あるいはそれ以降が必要です。libc 5.4.46 での動作は確認されています。glibc 2.0.6 およびそれ以降もまた動作します。Red Hat 社の glibc RPM に問題があります。問題が発生した場合には、何か更新があるかチェックしてください。glibc 2.0.7-19 および 2.0.7-29 RPM の動作は確認されています。

Red Hat 8.0 あるいは新しい glibc 2.2.x ライブラリを使用している場合、mysqld が gethostbyaddr() でデッドする場合があります。これは新しい glibc ライブラリのこの呼び出しにスタック サイズ 128KB 以上が必要だからです。この問題を修正するには、mysqld を --thread-stack=192K オプションで実行します。(MySQL 4 の前に -O thread_stack=192K を使用します。）このスタック サイズはMySQL 4.0.10 あるいはそれ以降ではデフォルトですので、問題が発生することはないはずです

MySQL のコンパイルに gcc 3.0 あるいはそれ以降を使用している場合、MySQL をコンパイルする前に libstdc++v3 ライブラリをインストールする必要があります。それをインストールしなかった場合、リンク中に __cxa_pure_virtual 記号が不明のメッセージが表示されます。

Linux ディストリビューションの旧バージョンの中には、configure が以下のようなエラーを表示するものもあります。

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

エラーメッセージに従ってその通りに作業します。アンダースコアが 1 つだけの _P マクロ名にもう 1 つのアンダースコアを加えて、再度試します。

コンパイルする時に警告が発せられる場合があります。以下の表示は無視して構いません。

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'

mysqld が起動する時に常にコアをダンプする場合は、その問題は多分旧 /lib/libc.a に因ります。.その名前を変更し、次に sql/mysqld を削除し、新たに make install を行い再度試します。この問題は Slackware のインストールで既に幾つか報告を受けております。

mysqld をリンク中に以下のエラーが表示された場合、libg++.a が正しくインストールされていないことを意味します。

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

configure を以下のように実行すると libg++.a を使用しないで済みます。

shell> CXX=gcc ./configure

実装の際に、readdir_r() が破損する場合があります。その兆候としては SHOW DATABASES ステートメントが常に空のセットを返します。これは設定後のコンパイルする前に HAVE_READDIR_R を config.h から削除することで修正できます。

弊社の MySQL 5.1 の Alpha でのベンチマークおよびテスト スィートのテストでは、動作に問題がないものと思われます。

弊社では現在 MySQL のバイナリ パッケージを AXP 用 SuSE Linux 7.0、kernel 2.4.4-SMP、Compaq C compiler (V6.2-505) および Compaq C++ compiler (V6.3-006) に対して Alpha EV6 プロセッサを搭載した Compaq DS20 マシンでビルドしています。

供述のコンパイラは http://www.support.compaq.com/alpha-tools/ にあります。.これらのコンパイラを gcc の代わりに使用して、およそ 9-14% ほどよい MySQL パフォーマンスが出ています。

Alpha の MySQL には、-arch generic フラグをコンパイルに使用しており、このことはそのバイナリはすべての Alpha プロセッサで動作することを意味しています。また、バイナリの問題を避けるために静的にコンパイルしています。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

egcs を使用する場合、以下の configure 行が弊社では機能しました。

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

MySQL を Linux-Alpha で動作させた場合の既知の問題:

MySQL は MkLinux 上では最新の glibc パッケージで動作します (glibc 2.0.7 でのテスト)。

MySQL を Qube2 (Linux Mips) で動作させるには、最新の glibc ライブラリが必要です。glibc-2.0.7-29C2 は動作するといわれています。また egcs C++ コンパイラ (egcs 1.0.2-9、gcc 2.95.2 あるいはそれ以降) を使用する必要があります。

MySQL を Linux IA-64 でコンパイルするには、弊社では以下の configure コマンドを gcc 2.96 でビルドする際に使用しています。

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

IA-64 には、MySQL クライアントは共有バイナリを使用します。このことは弊社のバイナリ ディストリビューションを /usr/local/mysql と異なるロケーションにインストールするには、libmysqlclient.so をインストールしたディレクトリのパスを /etc/ld.so.conf ファイルあるいは LD_LIBRARY_PATH 環境変数の値のいずれかに追加する必要があります。

項B.1.3.1. 「Problems Linking to the MySQL Client Library」 を参照してください。

RHEL4 は SELinux と一緒に出荷され、プロセスのタイトなアクセスをサポートします。If SELinux が有効になると (/etc/selinux/config の SELINUX が enforcing に設定され、SELINUXTYPE が targeted あるいは strict のいずれかに設定される)、MySQL AB RPM パッケージをインストールする際に問題に遭遇する場合があります。

Red Hat 社にはこの問題を修正する更新版があります。その中にはMySQL AB が提供した RPM のインストール構成を処理する 「セキュリティ ポリシー」 の仕様が含まれています。詳細は、https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167551 および http://rhn.redhat.com/errata/RHBA-2006-0049.html を参照してください。

MySQL は大きな問題なしに Mac OS X 10.x (Darwin) で動作する必要があります。

既知の問題：

弊社の Mac OS X 用バイナリは Darwin （ダーウィン）6.3 に以下の configure 行でコンパイルしています。

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

項2.5. 「Mac OS X に MySQL をインストールする」 を参照してください。

現在の Mac OS X サーバには、MySQL をコンパイルする前のオペレーティング システムの変更は必要ありません。サーバ プラットフォームのコンパイルは Mac OS X のクライアント バージョンの場合と同じです。

旧バージョン (Mac OS X Server 1.2、a.k.a. Rhapsody) には、MySQL を設定する前に最初に pthread パッケージをインストールする必要があります。

項2.5. 「Mac OS X に MySQL をインストールする」 を参照してください。

通常、Solaris 2.6 のバイナリを Solaris 2.7 および 2.8 で使用できます。Solaris 2.6 公開版のほとんどもまた Solaris 2.7 および 2.8 に適用できます。

MySQL は自動的に Solaris の新バージョンを検知して以下の問題に対して回避策を取ります。

Solaris 2.7 / 2.8 の include ファイルにはいくつかバグがあります。gcc を使用すると以下のエラーが表示される場合があります。

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

この問題が発生したら /usr/include/widec.h を .../lib/gcc-lib/os/gcc-version/include にコピーして行 41 を以下から：

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

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

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

また、/usr/include/widec.h を直接編集することもできます。いずれの場合も、修正を加えた後に config.cache を削除し configure を再度実行します。

make を実行した時に以下のエラーが表示された場合、configure が curses.h ファイルを検知できなかったことを意味します (多分 /usr/include/widec.h のエラーによる)。

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

この問題を解決するには以下のいずれかを実行します。

クライアント プログラムをリンク中にリンカが -lz を見つけられない場合、その問題は多分 libz.so ファイルが /usr/local/lib にインストールされているからです。この問題を解決するには以下のメソッドのいずれかを実行します。

x86 の Solaris 8 では、strip を使用してデバッグ記号を削除すると mysqld がコアをダンプします。strip.

gcc あるいは egcs を Solaris x86 で使用中の負荷下でにコア ダンプの問題が発生したら、以下の configure コマンドを使用します。

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

これにより libstdc++ ライブラリおよび C++ 例外で問題を回避します。

これで問題が解決できない場合、デバッグ バージョンをコンパイルし、それをトレース ファイルあるいは gdb　で実行します。Debugging mysqld under gdb 参照。

スレッド パッケージよく統合されているため、MySQL の使用に FreeBSD 4.x あるいはそれ以降の使用をお勧めします。セキュアで安定してシステムにするには、-RELEASE の印の付いた FreeBSD kernel のみを使用します。

MySQL のインストールで最も容易（で推奨される）な方法は mysql-server ポートおよび mysql-client ポートを使用することです。それらは http://www.freebsd.org/ で入手できます。これらのポート使用することで以下のメリットがあります。

MIT-pthreads を FreeBSD 2.x で、ネイティブ スレッドを FreeBSD 3 およびそれ以降で使用するようお勧めします。ネイティブ スレッドを 2.2.x バージョンで動作できますが、mysqld のシャットダウンの問題が発生する場合があります。

不幸にも、FreeBSD のある種の関数のコールがまだ完全にスレッド セーフになっていません。最も注目に値するのは、これには gethostbyname() 関数が含まれているので、これによって MySQL でホスト名を IP アドレスに変換できます。ある環境下では、mysqld プロセスが突然 100% CPU 負荷になり、応答がなくなります。この問題に遭遇した場合には、--skip-name-resolve オプションを使用して MySQL を起動してみます。

あるいは、FreeBSD の MySQL を LinuxThreads ライブラリにリンクすることによって、ネイティブの FreeBSD のスレッド実装による幾つかの問題を回避することができます。LinuxThreads とネイティブ スレッドの比較をよくまとめた Jeremy Zawodny の記事 あなたの MySQL サーバにどちらを選ぶ、FreeBSD それとも Linux ？ が http://jeremy.zawodny.com/blog/archives/000697.html にあります。

FreeBSD 上の LinuxThreads の既知の問題:

MySQL ビルド プロセスが機能するには GNU make (gmake) が必要です。GNU make が利用できない場合、MySQL をコンパイルする前にインストールする必要があります。

gcc (2.95.2 and up) の FeeBSD に MySQL をコンパイルしてインストールする方法として推奨しているのは：

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
cd /usr/local/mysql
bin/mysql_install_db --user=mysql
bin/mysqld_safe &

configure が MIT-pthreads を使用している場合、MIT-pthreads の注釈を読む必要があります。項2.9.5. 「MIT-pthreads ノート」 参照。

make install から /usr/include/pthreads が見つからないとのエラーが表示された場合、configure が MIT-pthreads に必要なそれを検知しなかったことになります。.この問題を修正するには、config.cache を削除して、次に configure を --with-mit-threads オプションで実行します。

名前のリゾルバーが正しく設定されているか確認します。正しく設定されていないと、リゾルバーの遅延あるいは mysqld への接続に失敗します。また、localhost の /etc/hosts ファイルへのエントリが正しいか確認します。このファイルは以下のような行で実行されます。

127.0.0.1       localhost localhost.your.domain

FreeBSD は非常に小さいデフォルトのファイル処理制限があることで知られています。項B.1.2.17. 「'File' Not Found and Similar Errors」 参照。サーバを --open-files-limit オプションを使用して mysqld_safe に起動しするか、あるいは /etc/login.confg の mysql ユーザーの制限を上げそれを cap_mkdb /etc/login.conf で再度ビルドします。また、デフォルト (chpass mysqld-user-name を使用する) を使用していない場合、パスワード ファイルのこのユーザーに適切なクラスを設定しているか確認します。項4.3.1. 「mysqld_safe ? MySQL サーバ スタートアップ スクリプト」 参照。

FreeBSD の制限はで、システムに利用できる大きな RAM がある場合でも、プロセスのサイズを 512MB に制限します。それで以下のようなエラーが表示されます。

Out of memory (Needed 16391 bytes)

現在のバージョンの FreeBSD (最低でも 4.x およびそれ以降) では、この制限を以下のエントリを /boot/loader.conf ファイルに追加し、マシンをリブートして増やすことができます (これらはランタイム時に sysctl コマンドで変更できる設定ではありません)。

kern.maxdsiz="1073741824" # 1GB
kern.dfldsiz="1073741824" # 1GB
kern.maxssiz="134217728" # 128MB

FreeBSD の旧バージョンでは、kernel を再コンパイルしてプロセスの最大データ セグメント サイズを変更する必要があります。この場合の詳細に関しては LINT 設定ファイルの MAXDSIZ オプションを参照してください。

MySQL の現在の日付で問題がある場合には、TZ 変数の設定が役に立ちます。項2.14. 「環境変数」 参照。

NetBSD でコンパイルするには、GNU make が必要です。それがないと、ビルド プロセスは make が lint を C++ ファイルで実行する際に失敗します。

OpenBSD 2.5 では、MySQL をネイティブのスレッドで以下のオプションを使用してコンパイルできます。

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

MySQL をコンパイル中に以下のエラーが表示された場合、仮想メモリの ulimit 値が小さすぎます。

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

ulimit -v 80000 を使用して試し make を再度実行します。.これで修正できずしかも bash を使用している場合には、csh あるいは sh に切り替えてみます。BSDI のユーザー数社から bash と ulimit の問題が報告されています。

gcc を使用している場合、--with-low-memory フラグを configure に使用して sql_yacc.cc をコンパイルすることもできます。

MySQL の現在の日付で問題がある場合には、TZ 変数の設定が役に立ちます。項2.14. 「環境変数」 参照。

BSD/OS 3.1 へのアップグレード。アップグレードできかなった場合、BSDIpatch M300-038 をインストールします。

MySQL を設定する際以下のコマンドを使用します。

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

以下が動作することが知られています。

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

任意にディレクトリのロケーションを変更できます。特に指定するロケーションがない場合はデフォルトを使用します。

高負荷でパフォーマンスに問題がある場合には、--skip-thread-priority オプションを mysqld に試してみてください。これによりすべてのスレッドを同じ優先度で実行します。BSDI 3.1では、少なくとも BSDI がそのスレッド スケジューラを修正すればよい性能がでます。

コンパイル中にエラー virtual memory exhausted が表示されたら、ulimit -v 80000 を使用してみて make を再度実行します。これで修正できずしかも bash を使用している場合には、csh あるいは sh に切り替えてみます。BSDI のユーザー数社から bash と ulimit の問題が報告されています。

BSDI 4.x にはスレッド関連のバグが幾つかあります。これに MySQL を使用する場合には、スレッド関連のすべてのパッチをインストールする必要があります。少なくとも M400-023 はインストールしてください。

BSDI 4.x システム上で、共有ライブラリに問題がある場合もあります。問題の兆候としては、どのクライアント プログラムも、例えば mysqladmin を実行できません。.この場合、共有ライブラリを --disable-shared オプションで設定しないように再設定します。

カスタマーの中には BSDI 4.0.1 で mysqld バイナリがしばらくの間テーブルを開かないとの問題が出ています。この問題はライブラリ/システム関連のバグによって mysqld が現在のディレクトリの変更要求を出さずに現在のディレクトリを変更するからです。

これを修正するには MySQL を最低でもバージョン 3.23.34 にアップグレードするか、configure の実行後に行 #define HAVE_REALPATH を config.h から make を実行する前に削除します。

これはデータベース ディレクトリをシンボリカルに別のデータベース ディレクトリにリンクできない、あるいはテーブルを別のデータベースにシンボリックにリンクできないことを意味します。(シンボリックに別のディスクにリンクすることはできます)。