Go to the first, previous, next, last section, table of contents.


MySQL はどれくらい安全/安定か

MySQL はどれくらい安定か?

TcX では、MySQL は 1996 中頃から我々のプロジェクトで何の問題も なく動いていました。広く公にリリースされた時、我々は、MySQL 内 に 'テストされていないコード' の部分があることに注意しました。これは、異 なる方法でクエリを作成する新しいユーザグループによって速く見つけられまし た。新しい各リリースは、多くの新しい機能を持っているのに、前のものよりも 問題は少なくなります。そして次のリリースの一つを '安定' と呼ぶことができ るように我々は望んでいます。

MySQL の各リリースは実用的で、ユーザが 'グレイゾーン' からのコー ドの使用を開始する時にだけ問題があります。当然、外部のユーザは、何がグレ イゾーンかを知ることができません。そして、このセクションで現在知られてい るこれらを明らかにしたいと思います。

我々はここで、多くの人に関係すると思われるさらに重要な質問のいくつかに回 答し、いくつかの問題を明らかにしようと思います。このセクションは、とても 活発にバグが報告されているメーリングリストからの情報が一緒に置かれていま す。

MySQL はどのように安定しているのか? 私はこのプロジェクトで MySQL をあてにできるのか?

これは MySQL の 3.21.x バージョンについてです。知られていて報告 されたバグは BUGS ファイルにリストされているバグ(これは '計画' されてい ることです)を除き、全て最新バージョンで修正されます。

MySQL は複数の階層と異なった独立モジュールで書かれています。異 なったモジュールのリストとそれぞれがどのようにテストされているかがここに あります。

ISAM テーブル処理。安定
これはデータが格納されている全てです。全ての MySQL リリースでは、 このコード内には(報告された)バグは一つもありません。不正なテーブルを得る 唯一の方法は、更新の途中にあるサーバを殺すことだけです。そして各クエリ間 で全てのデータはディスクにフラッシュされるため、even this is unlikely to destroy any data beyound rescue. MySQL 内のバグのためにデータが 失われたというバグレポートは一つもありません。
パーサと単語解析。安定
このシステム内には2、3ヶ月は報告されたバグは一つもありません。
C クライアントコード。安定
知られた問題はありません。3.20 リリースの初期には、送信/受信バッファサ イズにいくつかの制限がありました。3.21.x では、送信/受信バッファはデフォ ルトの 512k まで動的に大きくなります。
mysql, mysqladmin そして mysqlshow。安定
コマンドラインクライアントにはほとんどバグはありません。
mysqldump と mysqlimport。 ベータ
3.21 で書き直されました。
基本的な SQL。安定
基本的な SQL 機能システムと文字列節と動的メモリ処理。このシステムには報 告されたバグは一つもありません。
クエリオプティマイザ。ガンマ
3.21 でいくつか変わりました。
範囲オプティマイザ。アルファ
3.21.x で全体的に書き直されました。
結合オプティマイザ。ガンマ
3.21 で少し変わりました。
GROUP BY, ORDER BY and related function COUNT(). Beta
3.21 で書き直され、通してテストされました。
ロック。ガンマ
これはとてもシステムに依存しています。いくつかのシステムでは、これは、標 準 OS ロック (fcntl) を使用するため大きな問題があります。これらの場合で は、MySQL デーモンを --skip-locking フラグつきで動かすべ きです。知られた問題は、いくつかの Linux システムと NFS マウントされたファ イルシステム使用時の SunOS です。
Linux スレッド。ガンマ
見つかっている問題は fcntl() コールでだけです。これは --skip-locking の使用で修正できます。何人かは 0.5 リリースで lockup 問題を報告しました。
Solaris 2.5+ pthread。安定
我々は、我々の全ての製品でこれを使用します。
MIT スレッド (他のシステム)。ベータ
3.20.15 から報告されたバグはありません。3.20.15 から知られたバグはありま せん。いくつかのシステムでは、いくつかの操作が遅くなるという 'misfeature' があります(1/20 秒の sleep が各クエリ間で行なわれます)。もちろん、MIT ス レッドはすべてを少し遅くします。しかしインデックスベースの select では、 select は通常一度に組み立てられるため、mutex locking/thread juggling は ありません。
他のスレッド実装。アルファ
他のシステムへの移行はまだとても新しく、そして、MySQL に、しか し一番多いのはスレッド実装自身に。多くのバグを持っています。
LOAD DATA..., INSERT ... SELECT。安定
何人かの人はこの中にバグを見つけたと考えましたが、それは結局誤解でした。 バグの報告の前にマニュアルを良くチェックしてください!
ALTER TABLE。ガンマ
3.21 で部分的に書き直されました。
mysqlperl。安定
沢山のコンパイルとリンクの問題を除いて、バグは報告されていません。
DBD。ベータ
現在、Jochen Wiedmann wiedmann@neckar-alb.de によってメンテ中です。感謝!
mysqlaccess。ベータ
Yves.Carlier@rug.ac.be によって書かれメンテされてます。感謝!
技術ドキュメント。ベータ
改良中。
MyODBC (uses ODBC SDK 2.5). Beta
いくつかのプログラムでちゃんと働いているように見えます。

TcX は代金を支払った顧客のために email サポートを提供しています。しかし MySQL メーリングリストは通常、全ての一般的な質問に答えを提供し ています。バグは通常すぐに通常に働くパッチで修正され、深刻なバグには、ほ とんどいつも新しいリリースがあります。

何故 MySQL にはそんなに多くのリリースがあるのか?

MySQL は TcX においてとても速く進化しています。そして我々はこれ を他の MySQL ユーザと共有したいです。我々は、他の人が必要とする ようなとても便利な機能を作った時に、リリースの作成をします。

我々は実装が簡単な機能を要求するような人の手助けもします。我々はライセン スされたユーザが欲しがるものにも注目し、そして特に我々の拡張 email サポー ト顧客が欲しいものに注目し、手助けします。

新しいリリースをダウンロードする必要はありません。News ファイルは、新し いリリースが、あなたが本当に欲しい何かを持っているかどうかを知らせます。 「MySQL change history」節参照 。

万一、リリース中に致命的なバグがあった場合、我々は、新しいリリースをでき るだけすぐに作成します。他の会社もそうすることを望みます :)

3.21.x バージョンは、多くの異なるシステムから主要な可搬性の変更を取り入 れました。3.21 リリースが安定する時、我々は alpha/beta 拡張子を取り除き、 開発活動は 3.22 に移ります。バグは安定バージョンでもまだ修正されます。こ れが、バグ修正と '行なうべき' ことをやめるような、完全な凍結とは信じてい ません。'いくらか凍結した' とは '既に動作していることにほとんど確実に影 響をあたえないような' 小さなことを追加するかもしれないことを意味します。

古いシステムを実行していて、アップグレードしたいけれども、3.21 にはした くない場合、3.20.32 にアップグレードすべきです。このバージョンでは、致命 的なバグの修正、小さくすること、比較的安全な変更だけが試みられました。

MySQL を初めて試している場合、または現在のシステムのテストのた めに少しの時間がある場合は、3.21 を使用すべきです。

エラーのためのテーブルのチェック

全てのデータがディスクに書き出されていない時に MySQL がクラッシュ した場合 (例えばコンピュータがとまった場合)、テーブルは不正になります。テーブルをチェッ クするには、次を使用します:

isamchk table_name
これはすべてのエラーの 99.99 % を見つけます。見つけ出せないものは、デー タファイルが不正だった時だけです。
isamchk -e table_name
これは全てのデータについて完全なチェックを行います。全ての行について全て のキーが、実際に正しい行を示すかをチェックするため check-read を行います。 これは、多くのキーを持つ大きなテーブルでは長い時間を要します。isamchk は 通常は最初に見つけたエラーの後で停止します。さらに情報を得たい場合は --verbose (-v) スイッチを isamchk に追加できます。 通常の使用では単純な 'isamchk' で十分安全です!
isamchk -e -i table_name
上記と同じですが、いくつかの統計を表示します。

我々は TcX で、我々の全ての重要なテーブルに対し、週に一度 cron ジョブを動かし ています。

35 0 * * 0 /path/to/isamchk -s /path/to/dbs/*/*.ISM

これは、クラッシュしたテーブルを出力します。それから我々は進み、検査し、必要な らば修復することができます。

我々は、予期しないテーブルのクラッシュは (ハードウェアトラブルを除いて) この2〜3年ありません (これは本当に真実です) 。週に一度は我々にとって十分 以上です。

もちろん、マシンが更新の途中でリブートを行なう時はいつも、通常、影響され ていた全てのテーブルをチェックする必要があります。(これは '予期されたテー ブルのクラッシュ' です)

我々が信用しているのと同じくらい MySQL を信用できるまでは、毎晩 isamchk -s を全ての更新されたテーブルに行なうことを勧めます。

普通は、safe_mysql にチェックを追加します。リブート後に古い pid ファイル が残っていた場合、24時間以内に変更された全てのテーブルをチェックすべきです。

テーブルの修復方法

MySQL がデータを格納するために使用するファイル形式は、広くテス トされています。しかし、いくつかのテーブルが不正になっという、実例は常にありま す (書き込み中の mysqld プロセスのハード kill、ハードウェアエラーまたは 予期せぬコンピュータのシャットダウンのように)。

不正なテーブルの前兆は通常、クエリが予期しないでアボートし、次のようなエラーが 得られます:

これらの場合、あなたのテーブルを修復する必要があります。isamchk 外部ユーティリ ティは通常、不正になっている多くのことの検出と修復ができます。 「MySQL テーブルチェック, 最適化そして修復プログラム」節参照 。

とても大きなファイルで isamchk を使用しようとする場合、最初に isamchk に どれくらいのメモリを与えたいかを決定すべきです。より多くのメモリを与える とより速くなります。例えば、32M RAM よりも多く持っていれば、次を試して下 さい:

isamchk -O sortbuffer=16M -O keybuffer=16M -O readbuffer=1M
        -O writebuffer=1M ....

MySQL のアップグレード/ダウングレード時に特別に行なうことが何かあるか?

MySQL 形式とデータファイルは、MySQL が同じベースバージョ ンである限り、同じアーキテクチャ上の異なるバージョン間でいつでも移動でき ます。現在のベースバージョンはもちろん 3 です。MySQL のリコンパ イルによって文字セット(ソート順)が変更された場合、テーブルに isamchk -r -q を行なう必要があります。

もしあなたが神経質または新しいバージョンを恐れている場合、いつでもあなた の古い mysqld を mysqld-'old-version-number' にリネームできます。もし新 しい mysqld が予期せぬ何かを行った場合、単純にそれをシャットダウンし、古 い mysqld を再起動することができます!

アップグレード時には、もちろん古いデータベースのバックアップをとっておく べきです。時々は少し神経質になるのは良いことです!

3.21 から 3.22 バージョンへのアップグレード

互換性に影響する変更はありません。DATE 型を伴い生成された新しいテーブル は日付の格納に新しい方法を使用することだけが pitfall です。これは古い バー ジョンの mysqld からこの項目をアクセスできないことを意味します。

C インタフェース mysql_real_connect() は変更されました。これを呼び出す古 いクライアントプログラムを持っている場合は、新しい DB 引数に 0 を置く (またはより速い接続のために db 要素を送るようにクライアントをコーディン グしなおす) 必要があります。

3.20 から 3.21 バージョンへのアップグレード

既に稼働中の 3.0.28 より前のバージョンを持っていて、3.21.# に変更したい 場合は、次を行なう必要があります:

safe_mysqld --old-protocolmysqld 3.21 サーバを起動すれ ば、オリジナルの 3.20 配布からのクライアントを使用できます。この場合、新 しいクライアント関数 mysql_errno() はサーバのエラーは何も返さず、 CR_UNKNOWN_ERROR だけを返します (ただしこれはクライアントエラーに ついては働きます)。そして サーバは古い password() チェックを新しいものの 代わりに使用します。

--old-protocol使わない場合:

MySQL 3.20.28 とそれ以降は、クライアントに影響を及ぼさずに、新 しい user テーブル形式を操作することができます。バージョン 3.20.28 より 前の MySQL を持っている場合は、user テーブルを変換すると、パス ワードはそれ以上働きません。安全のため、最初に少なくとも 3.20.28 にアッ プグレードし、それから 3.21.# にアップグレードすべきです。

新しいクライアントコードは 3.20.# mysqld サーバで動きます。そして、もし 3.21.# で問題を体験した場合は、クライアントをもう一度再コンパイルするこ となしに、古い 3.20.# サーバを使用することができます。

mysqld にオプション --old-protocol を使用しない場合、古い クライアントはエラーメッセージを発します:

新しい perl インタフェース DBI/DBD は古い mysqlperl インタフェースもサポー トします。mysqlperl を使用する場合に行う必要のある変更は、connect() 関数 の引数の変更だけです。新しい引数は次です: host,database,user,password (user & password 引数の順番が変更されました)。

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

他のアーキテクチャへのアップグレード

現在 MySQL データファイル *.ISM と *.ISD はアーキテクチャ依存で す。アプリケーションを他のアーキテクチャに移したい場合は、mysqldump を使 用すべきです。

mysqldump は (デフォルトでは) 他のマシンへ移行でき、mysqld サーバへの入 力として与えることができる完全な SQL ステートメントファイルを生成します。

使用できるオプションをチェックするために、mysqldump --help を試せ ます。

2つの接続されたマシン間でデータベースを移動する最も簡単な方法 (最も速い ではなく) は、データベースがあるマシン上で次を実行することです:

mysqladmin -h 'other hostname' create database
mysqldump --quick --drop database | mysql -h 'other hostname' database

ファイルの結果を格納することもできます (この例では圧縮されています):

mysqldump --quick databasename | gzip > databasename.contents.gz

# transfer the contents files to the target machine and use this
# on the target machine

mysqladmin create databasename
gunzip < databasename.contents.gz | mysql databasename

mysqldump と mysqlimport をこのために使用することもできます: (これは大きなテーブルに mysqldump を単純に使用するよりもとても速いです)

mkdir full-path-to-some_dir
mysqldump --tab=full-path-to-some-dir database

# transfer the contents files to the target machine and use this
# on the target machine

mysqladmin create database
cat full-path-to-some_dir/*.sql | mysql database
mysqlimport database some_dir/*.txt

'mysql' データベースのコピーも忘れないでください。mysql データベースをそ の場所に置くまで、新しいマシン上では "root" ユーザで MySQL を使 用する必要があります。

最後に (または 'mysql' データベースの導入直後) 新しいマシン上で次を行い ます: mysqladmin reload

2000 年対応

MySQL は Unix times 関数を使用し、2069 年まで日付には何の問題も ありません; 全ての2桁の年は 1970-2069 の範囲にあると見なされます。 MySQL 3.22 では、新しい YEAR 項目型が 0, 1901-2155 を1バ イトで格納でき、2または4桁で表示できます。


Go to the first, previous, next, last section, table of contents.