TcX では、MySQL は 1996 中頃から我々のプロジェクトで何の問題も なく動いていました。広く公にリリースされた時、我々は、MySQL 内 に 'テストされていないコード' の部分があることに注意しました。これは、異 なる方法でクエリを作成する新しいユーザグループによって速く見つけられまし た。新しい各リリースは、多くの新しい機能を持っているのに、前のものよりも 問題は少なくなります。そして次のリリースの一つを '安定' と呼ぶことができ るように我々は望んでいます。
MySQL の各リリースは実用的で、ユーザが 'グレイゾーン' からのコー ドの使用を開始する時にだけ問題があります。当然、外部のユーザは、何がグレ イゾーンかを知ることができません。そして、このセクションで現在知られてい るこれらを明らかにしたいと思います。
我々はここで、多くの人に関係すると思われるさらに重要な質問のいくつかに回 答し、いくつかの問題を明らかにしようと思います。このセクションは、とても 活発にバグが報告されているメーリングリストからの情報が一緒に置かれていま す。
MySQL はどのように安定しているのか？ 私はこのプロジェクトで MySQL をあてにできるのか？
これは MySQL の 3.21.x バージョンについてです。知られていて報告 されたバグは BUGS ファイルにリストされているバグ(これは '計画' されてい ることです)を除き、全て最新バージョンで修正されます。
MySQL は複数の階層と異なった独立モジュールで書かれています。異 なったモジュールのリストとそれぞれがどのようにテストされているかがここに あります。
--skip-locking フラグつきで動かすべ
きです。知られた問題は、いくつかの Linux システムと NFS マウントされたファ
イルシステム使用時の SunOS です。
--skip-locking の使用で修正できます。何人かは 0.5 リリースで
lockup 問題を報告しました。
TcX は代金を支払った顧客のために email サポートを提供しています。しかし 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
isamchk -e table_name
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 ....
shell> mysql database mysql> delete from table_name; mysql> quit
MySQL 形式とデータファイルは、MySQL が同じベースバージョ
ンである限り、同じアーキテクチャ上の異なるバージョン間でいつでも移動でき
ます。現在のベースバージョンはもちろん 3 です。MySQL のリコンパ
イルによって文字セット(ソート順)が変更された場合、テーブルに
isamchk -r -q を行なう必要があります。
もしあなたが神経質または新しいバージョンを恐れている場合、いつでもあなた の古い mysqld を mysqld-'old-version-number' にリネームできます。もし新 しい mysqld が予期せぬ何かを行った場合、単純にそれをシャットダウンし、古 い mysqld を再起動することができます！
アップグレード時には、もちろん古いデータベースのバックアップをとっておく べきです。時々は少し神経質になるのは良いことです！
互換性に影響する変更はありません。DATE 型を伴い生成された新しいテーブル は日付の格納に新しい方法を使用することだけが pitfall です。これは古い バー ジョンの mysqld からこの項目をアクセスできないことを意味します。
C インタフェース mysql_real_connect() は変更されました。これを呼び出す古 いクライアントプログラムを持っている場合は、新しい DB 引数に 0 を置く (またはより速い接続のために db 要素を送るようにクライアントをコーディン グしなおす) 必要があります。
既に稼働中の 3.0.28 より前のバージョンを持っていて、3.21.# に変更したい 場合は、次を行なう必要があります:
safe_mysqld --old-protocol で mysqld 3.21 サーバを起動すれ
ば、オリジナルの 3.20 配布からのクライアントを使用できます。この場合、新
しいクライアント関数 mysql_errno() はサーバのエラーは何も返さず、
CR_UNKNOWN_ERROR だけを返します (ただしこれはクライアントエラーに
ついては働きます)。そして サーバは古い password() チェックを新しいものの
代わりに使用します。
--old-protocol を使わない場合:
scripts/add_long_password を、'mysql/user' テーブル内
のパスワード項目を char(16) に変換するために実行する必要がありま
す。
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 を試せ
ます。
２つの接続されたマシン間でデータベースを移動する最も簡単な方法 (最も速い ではなく) は、データベースがあるマシン上で次を実行することです:
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
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.