最近あまりMLでバグの話を聞きませんが、問題ないのでしょうか。

岸本

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

http://dev.mysql.com/tech-resources/articles/choosing_mysql.html

正しいMySQLの版を選び方とバグをレポートする方法

Arjen Lentz著

よくどのMySQLの版を使ったら良いか、アップグレードを考えるべきか、
バグを発見したらどうするかと聞かれます。こういうことは
MySQLレフェレンス・マニュアルやその他でふれられていますが、
この記事ではこいいった重要な懸案について語ります。

どんな版があるのでしょうか。

選択する前に実際に何があるかまず見ましょう。いつも同時に複数の
版が存在します。最初は少し迷うかもしれません。

今は
    * MySQL 4.0 - 前のプロダクション・リリース
    * MySQL 4.1 - GA(generally available)・プロダクション
    * MySQL 5.0 - アルファ

ダウンロードするときに、余分な番号があるのに気がつくでしょう。
例えば"4.1.10"です。"10"はシリーズの中のビルドの番号です。
どの版を使うか他の人と話をするときは、全部の番号を指定
する必要があります。例えば、「4.1.10を使っています。」
という具合に。それで他の人がどの版かはっきりと分かり
ます。「最新版を使っています。」でははっきりと
は分かりません。

MySQLの版を確かめたい場合は、SELECT VERSION()というコマンド
を使用すると分かります。MySQL サーバーは１行1列で版の
番号をストリングで返還します。クライアントの版とサーバーは必ずしも
同じではないので注意してください。

実際には上記以上のフェーズがあります。概要は：

    * アルファは開発が続いており、新しい機能が追加されています。
異なった新しい開発のグループ同士が相互関連することがあり、後の版
に対する影響があります。新しい機能を追加するのは時として
複雑です。正しいソフトウエア工学の方法を使用しており、設計を
コードを書いたり、インテグレートする前にしっかりと行います。
しかし、ときどきアルファ時でも設計に変更があります。これは実際
にどのように良い設計がなされても。実世界での経験とフィードバック
にはかなわないからです。
    * ベータは"機能フリーズ"ということです。与えられたシリーズ
の全ての新しい機能が実装されています。それで基本的には
もう変更がありません。これは開発プロセスなかでは、安定させる
フェーズと位置づけます。フォーカスは実装からバグ・フィックスへと変更されます。 

もう新しいコードが実装されないので、バグフィックスのスピード
があがります。
    * ガンマは"リリース候補"といえます。MySQLの版はアルファから
入手可能です。その意味ではこれはクローズド・ソースの
会社が言っているような意味でのリリースではありません。
ここでは"プロダクション品質"の版に向けていくと
いう意味でリリースという言葉を使用します。ベータでのバグ・フィックス
の後でガンマに移行するというのは、全体の進み具合が順調だと
いうことです。プロダクションの使用に耐えうるというお墨付き
を貰える状態に近いということです。何も変なことが起こらない
ことを確かめたいのです。
    * プロダクションは次のステップです。これはこのシリーズが
プロダクションでの使用に耐えるとみなされたということです。
これを"GA" (Generally Available)とも呼びます。この語句は
エンタープライズのポリシーでよく使われるからです。プロダクション
版でもバグがあることがあります。バグなしのソフトはありません。
プロダクション・フェーズではレポートされたバグは修正されます。
しかし、これはサーバーの全体の動作を変えないときに限ります。
動作が変わるとアプリに悪い影響を与えるかもしれないからです。
ある場合にはバグ修正にコードの変更が多すぎて、コードが
不安定になったりします。そのような場合は問題点をドキュメント
に書いて次のシリーズで修理します。１つのプロダクション
シリーズを利用している人は同じシリーズの新しいリリースに安全に
問題なくアップデートできます。例えば、4.1.10から4.1.11です。
    * 前の版というのは以前のプロダクション版です。
簡単なバグは修正されます。セキュリティの問題などです。 それでも
他の動作に影響があってはいけません。

それではどうやって、あるシリーズが開発されるのでしょう。
5.0 の最初は4.1のブランチから生成されました。
２つは並列に異なった開発者が異なった部分について
同時開発をしています。ブランチは少し内容が変わってきたので
（設計の変更で）いつも、同じパッチを適用できる
とはかぎりません。リリースの前に下の版に（可能であれば）マージされます。
4.1シリーズでバグが修正され、5.0でも同じ問題がある場合は
同じ修正が適用されます。必要とあれば、他の方法で。

それぞれのシリーズ（例えば4.1とか 5.0) はそれぞれのリリース
のサイクルがあります。例えば4.1.0 はアルファ、4.1.3 は
ベータ、4.1.4 はガンマで、4.1.7 は最初のプロダクション版でした。
完全なログはここにあります。
 http://dev.mysql.com/doc/mysql/en/news.html

時々4.1.10aのような特別なリリースがあります。
これはある特定のプラットフォーム上のビルドの問題
か(つまりビルドのプロセスに問題あり、全く同じ
コードで新しいコンパイルをするとき）マイナーだが
重要な修正（セキュリティの問題）が新しいリリースの前
に必要な場合です。

あなたの選択

初めてMySQLを使い始めた方は最新のプロダクション・シリーズ
またはガンマ(あれば)をお使いください。良く環境がわかっている
のであまり変な状況に遭遇することはないでしょう。
たいていの人は自分の使用している版は良く知っています。

プロダクション環境ですぐにMySQLを展開するために選択する場合は
実行するアプリの要求をチェックしましょう。シスアドミは
保守的ですから、多分プロダクション・シリーズを選択する
でしょう。

新しいアプリを開発したり、新しいことを試したかったら、
最新版を試してみましょう。アルファでも。この版だと
アプリに最新の機能を提供しますし、新しい最適化も
利用できます。

バグはどうですか。いつあるMySQL シリーズがプロダクションと
なるんでしょうか。あなたのアプリがプロダクション・レベルに
達したときにあなたが使い始めたMySQLのシリーズも 成熟して
いるかもしれません。ベンダーの新しいOSに組み込まれている
かもしれません。

プロダクションにまで達していない場合でも、あなたはそのシリーズを
良く知っているし信用できます。開発やテストに使ってきた
わけですから、あなたの特定のアプリに対してどのように
動作するかわかっているでしょう。だから、あなた自身で
"プロダクションに耐えうる"と決定できるでしょう。

保守的に選択も出来ますが、カスタマーがインストールする
最新の版とあなたのアプリが一致しないかも知れません。
その場合はMySQLの機能を最適に使用できないかもしれません。
そうであれば、競争に遅れるかも知れません。そういった
ことも考慮してください。

リリースする前にはテスト・スイートのテストをパスしなければ
なりません。バグが発見されて修理された場合、テストケースを
テストスイートに追加して 将来の版のコードが"refactor"
されてもバグがキャッチされるようにです。

プロダクション・サイクルは技術的な面で決まり、マーケティング
で決まるものではありません。ユーザの皆様が私達のスケージュール
に合わせてMySQLの版を選択して頂ければ非常にありがたいです。
私達はロードマップに基づいて行動しており、メージャーな
リリースのスコープを限定しています。

ソース、バイナリ、またはRPM?

ダウンロードのページにアクセスすると、ダウンロードには
幾つかのオプションがあります。多くのプラットフォームに
対してバイナリーがあります。あればそれを使うことをお勧め
します。それは私達がこちらの環境でビルドしたものです。
正しいコンパイラーの版や全て必要で正しいライブラリーを
使用していますから。

あなたが欲しいプラットフォームにバイナリがない場合、ソース
からビルドすることが必要です。マニュアルでプラットフォームに
特有な情報を参照してください。ビルドの後ではテスト・スイート
を実行することをお忘れなく。

普通のバイナリのほか、Linux用にRPMも用意します。
RPMベースのLinux ディストリビューションを使用するので
あれば、これが一番簡単です。RPM のインストレーションは自動的に
プロセスをコントロールします。多くのインストレーション
の問題はインストラクションから簡単なステップを抜かしてしまうこと
に起因します。

何時アップデートするのが良いのしょうか。

基本的なルールは「壊れたのでなければ修理しないでおきましょう。」
です。まだ多くのプロダクション環境ではMySQL 3.22 やそれ以前
の版を使っています。ちゃんと動作しています。でもそれはその
版に合わせて開発されたアプリにのみ適用されます。その版の
後に修正されたバグもあれば、最適化された機能もあります。

一般論ではプロダクションと認定された場合、同じシリーズ
内では新しいリリース（ビルド）にアップデートして
も問題が生ずることはありません。4.1.10を使っていて4.1.11が
リリースされたら、最初に変更のログをチェックして
[http://dev.mysql.com/doc/mysql/en/news.html]
あなたに関係のあることが変更されたか確かめてください。もし
なにもなければ、問題ありません。もしMySQL Networkをサブスクライブ
しているのであれば、自動的に特定の版、プラットフォーム、
と使用されいる機能用のアップグレードが配信されます。
http://www.mysql.com/network/.

新しいシリーズにアップグレードするときは(例えば4.0から 4.1)、
まづ最初にマニュアルのアップグレード情報を読み注意深く
インストラクションに従ってください。

シリーズをスキップするのはお勧めではありません。つまり、
4.0 から5.0に行くとか3.23から 4.1へなどです。どうしても
必要なときはアップグレードのインストラクションを注意深く
読んでステージ毎に行うのがお勧めです。最初に3.23から4.0、
そして4.0 から4.1。もちろん、あなたのアプリのテスト
も間に含めて。

アップグレードしているときは、余分のバックアップをするのは
良い考えです。ちゃんとプロセスを踏んでいれば、アップグレードして
もデータが損なわれることはありません。しかし、どれだけ
注意深くしても、間違いは起こりえます。そのときに悔やまない
ためです。

シリーズ間のダウングレードはややこしいです。特別の注意
が必要で、マニュアルでいろいろと行わなければならないかも
知れません。幾つかのツールを利用できることもあります。例えば
mysqldumpにはMySQL 4.1からSQLダンプを生成するオプションが
あります。それをMySQL 4.0で読み込ませることができます。
MySQLマニュアルには以下のようにダウングレードの情報が
あります。http://dev.mysql.com/doc/mysql/en/downgrading.html.
しかし、できることならダウングレードは避けた方が良いです。

バグ

既に述べたように、バグがないソフトは存在しません。バグを
発見したら、"最高です!"と言わずにはおられません。
早速レポートしてください。他の誰かが既にレポートして
いるかも知れませんが、そうでないかも知れません。ですから
是非バグをレポートしてください。他のユーザ、サポートと
ソフトの品質のすべてにとって助けになります。バグのレポートはMySQL
の開発プロセスで一番大切なことだと言っても言い過ぎではありません。

ここでちょっとまとめて、前の章との関係を考えて見ましょう。
ソフトの品質はどれだけの人がそれを使うかに
かかっています。特に開発サイクルの初期ではそれが
重要です。それは、バグがレポートされて、修正される
かです。 この点ではMySQLは大きなユーザベースのおかげで素晴らしい
トラックレコードを持っています。全部の異なった環境やアプリ
を考えてみてください。

ここで面白い観察をしてみましょう。あるシリーズを当初（アルファやベータ）
から使用する人が多ければ多いほど、早くプロダクションのステージ
に達します。 反対に多くの人が保守的にシリーズを選択すると（古い
版を使用）、このシリーズの全体の開発サイクルに影響がでます。
時間が経てばソフトが成熟するというものではありません
(ワインならワイン倉に長く置けばよいかもしれませんが）。
実世界でテストされなければ、シリーズはなかなか成熟しません。
それは単にフィードバックの数が少ないからです。ですから
出来る限り保守的でなく進歩的な選択をしてください。

バグの話に戻ります。MySQL のバグのシステムはオープンで
http://bugs.mysql.com/で閲覧できます。ここにバグのレポート
ができます。既に同じバグがレポートされているか、バグ修正
の状況などの情報が入手できます。バグをレポートするとき
は以下を正しく提供してください。環境と再生可能なシナリオ。
私達の開発者は大変優秀です。しかし、千里眼ではありませんし
あなたの心を読むこともできません。どこで問題が生ずるのかが
分からないと修正のしようがありません。
再生可能のシナリオを提供するのは時として容易でないのは
理解できます。レポートした人以外からテストのシナリオ
が提供されることもあります。しかし、最初のレポートで
できるだけ詳細にはっきりと問題を指摘してください。

バグに関して１つだけ例外があります。それはセキュリティが
関わった場合です。セキュリティのバグは別なところに
行きます。 そこで、処理されて発表される前に修正されます。
セキュリティ・エージェンシの１つがMySQLやその他の
プログラムで問題を発見した場合は、ベンダーが何もしなくて
も発表を待ってはくれません。しかし、実際にはベンダーに
十分な時間をくれて修正させてくれます。これも良い
品質コントロールです。

最後に短いコメントです。残念なことにバグがバグレポートに
報告されずにオンライン・マニュアルのコメントや、フォーラム
のメッセージ、メーリングリストのメッセージなどに提供されて
いることです。これでは開発者にはバグの情報が届きません。
ですから、お願いですからバグシステムを使ってください。そうすれ
ばもっと早く問題が解決します。

バグレポートはMySQLサーバーだけでなく、他のユーティリティや
グラフィカルなツールについてもお願いします。

MySQL Networkとサーティファイド・バイナリ

サーティファイドされたバイナリはダウンロードできる
最新の"コミュニティ版よりももっと保守的なリリースサイクル
で提供されます。更に、サーティフィケーションを含む追加の
品質コントロールが施されます。プロダクション環境ではMySQL Network
サーティファイド・バイナリーだけを使った方が良いでしょう。
パートナーはアプリケーションをMySQL Network用にサーティファイ
できます。そしてその特定の環境だけをサポートすることができます。
MySQL Networkの詳細は http://www.mysql.com/network/

結論

この記事がお役に立ったかと思います。これはいつも覚えておいて
ください。ユーザのあなたはMySQLのシステムのなかで重要な
パートを担っているのです。あなたというユーザがいなけれが
このシステムは作動しません。MySQLを使ってくださって有難う
ございます。そしてバグレポートやいろいろなご意見も有難う
ございます。

---------------------
Zen Kishimoto                            www.ipdevices.com
IP Devices, Inc.                           zen@xxxxxxxxxx
2175 De La Cruz Blvd., Suite 10    (408) 567-9391
Santa Clara, CA 95050                (801) 720-8847 (FAX)