推奨ビルド&&テスト手順最新版
夏休みに突入したので書いてみる！MySQLをソースからビルドしてみたい人向け、最新版。MySQL 5.0.46をベースにしてます。
まずはダウンロード
MySQL Enterpirse Serverのソースダウンロードページはこちら。有償サポートを買った人向け。最近はftp://ftp.mysql.comではソース公開してないっぽい。GPLなのにいいのかな？
MySQL Community Serverのソースダウンロードページはこちら。
次はconfigure
configureオプションの選び方については先日書いたのでそちらを参照。Tritonn使わない人は--with-senna/--with-mecab不要。
configureが通らない場合、経験的には2パターンくらいかな。ひとつはzlib-develが入っていない場合、もうひとつはlibncursesが/usr/lib/libncurses.soではなくて/lib/libncurses.soに入っているLinuxディストリビューション(Debian系)を使っている場合。前者の場合はyumでもapt-getでも何でも良いから追加インストールする。後者の場合は以下のようにlibncursesの場所をconfigureオプションで指定してあげる。
--with-named-curses-libs=/lib/libncurses.so
コンパイル
単純にmakeでOK
パッケージング
ここが今回のポイントです。これまで"make install"じゃなくて"make bin-dist"とか言ってきましたが、実は"make bin-dist"にはひとつ余計な処理が入ってました。orz
現在のお勧めパッケージング方法は以下です。make_binary_distributionスクリプトを使います。注意点としては、オプションに"--no-strip"をつけるべしという点があります。
scripts/make_binary_distribution --no-strip
configureから順に書くと以下ですね。
./configure make scripts/make_binary_distribution --no-strip
このスクリプトを実行すると、ソースディレクトリのトップ階層にバイナリtarballができあがります。"make bin-dist"を実行すると、Makefileを読んでもらえれば分かりますが、引数無しで"scripts/make_binary_distribution"が実行されます。引数無しのmake_binary_distributionはMySQLのバイナリパッケージ（tarball版）を作り、mysqldをstripします。ここで"--no-strip"というオプションをつけてあげることで、最後の処理でmysqldをstripしないようになります。
stripとは何か、についての詳細は『Binary Hacks』を参照いただくとして、簡単に言うと対象のバイナリ(例えばmysqld)からシンボルを切り捨てることを意味します。
mysqldはSIGSEGVやSIGABORTなどのシグナルを受信した際、当然、プロセスが落ちてしまう（ぬっころされる）のですが、その死ぬ直前にエラーログにstacktraceを吐き出します。このとき、mysqldはアセンブラコードを使ってそれまでの呼び出しスタックを構成するフレームのアドレスを16進数でエラーログに書いてくれるわけです。またmysqldの起動オプションに--core-fileを指定していた場合には、coreファイルを吐き出します。
で、この時、mysqldがstripされていたかどうかで、その後の障害解析のしやすさが代わります。通常、stripするメリットとしては性能向上があるのですが、かつて（たぶんMySQL 4.0時代）は性能が最大で4%くらい向上するとリファレンスマニュアルにも書いてあったのですが、現在（たぶんMySQL 4.1時代くらいから）はその記述もリファレンスマニュアルからは削除されています。これは、その後のMySQLのさらなる開発と検証の結果、stripによる性能向上があまり大きなものではなくなりメリットが減少したためと、あとその障害発生時のcoreファイルやstacktraceからの障害解析のしやすさがstripしていない方が楽であるという点からこのようになったとされています。
厳密には、strip前に"nm --numeric-sort mysqld > mysqld.sym"とかでシンボル情報を残しておけば、stripした後も吐き出されるアドレスは代わらないのでstacktraceによる障害ポイントの特定はできるのですが、coreファイル解析は困難な状態ですので、やはりstripしないほうが良いという結論になります。
さて、このmake_binary_distribution実行後にできるtarballですが、ファイル名はconfigureオプションの--with-server-suffix、MySQLのバージョン、OS、CPUアーキテクチャなどにより決まります。例えば以下のような感じです。
mysql-enterprise-gpl-5.0.46-linux-x86_64.tar.gz
これはMySQL 5.0.46を--with-server-suffix=-enterprise-gplとして、LinuxのIntel64/AMD64上でビルドした場合の例です。
テスト
さて自分でテストした場合に気になるのが、バイナリのQA(品質保証)です。「ソースをいじってないのだから問題ないはず」と単純に考えるのはあぶないです。このQAはやり出せばきりが無いわけですが、最低限、誰でも簡単にできる方法を紹介しておきたいと思います。
先程ビルドしたtarballを展開し、その中のmysql-testディレクトリへcdします。そして以下を実行しましょう。
perl ./mysql-test-run.pl --force --udiff > test.log
mysql-test-run.plというのはMySQLの回帰テストを実行してくれるPerlスクリプトで、--forceは途中で失敗しても最後までやるための指定、--udiffは"unified diff"形式でログを吐いてねという指定です。後者は好みで外してもかまいません。ポイントは、このmysql-test-run.plは標準出力にテストログを出力するのでファイルに落としておくという点です。
別のコンソールを起動し、tailコマンドでログを見ながら終わるのを待ちましょう。マシンスペックに寄りますが、10分〜20分はかかります。
tail -f -n200 test.log
終わったら最後に結果まとめが出力されますが。以下、お勧めのチェック方法。
まず*やばい*問題が起きていないかを確認する方法。
grep "Lost connection" test.log
これを実行して、何かgrepに引っ掛かるようなら*やばい*問題が起きている可能性大です。これは回帰テストの中から実行しているMySQLクライアントがテスト対象のmysqldと通信中に「通信が切れた」という意味ですが、これが発生しているときにはほぼ間違いなくmysqldがSIGSEGVやSIGABORTでテスト中に死んでいます（mysqldが死んじゃったので通信が切れた）。ソースを弄っていないのにこれが発生するようなら、再現手順をメモった上で、http://bugs.mysql.comにレポートするといいかもです。
次に普通の問題が起きていないかを確認する方法。
grep "\[ fail" test.log
これは何かのSQLコマンドを発行したら想定していた結果と違う結果が返ってきた場合に該当します。このパタンは本当にMySQLが間違った結果を返している（＝まずい）場合もありますが、configureオプションの違い（MySQLが公式バイナリを作る際に使用しているオプションとの違い）により発生している場合もあり、その場合には問題ありません。
あるいはTritonn(MySQL+Senna)のようにMySQLの改造を行っている場合は、その改造部分に該当するテストは当然結果が異なることがあります。これらはケースバイケースで判断します。
通常、MySQL公式バイナリは上記の回帰テストを実行して全てPASSされていて、さらに追加のテストを行ってPASSされている状態でリリースされています。なので自分でビルドしたバイナリでPASSしないテストケースがある場合には、何らかの違いがでているということになります。
というわけでおしまいおしまい。
