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


H 他のシステムへの移植について

A working Posix thread library is needed for the server. On Solaris 2.5 we use SUN PThreads (the native thread support in 2.4 and earlier versions are not good enough) and on Linux we use LinuxThreads by Xavier Leroy, Xavier.Leroy@inria.fr.

The hard part of porting to a new Unix variant without good native thread support is probably to port MIT-pthreads. See `mit-pthreads/README' and Programming POSIX Threads.

The MySQL distribution includes a patched version of Provenzano's Pthreads from MIT (see MIT Pthreads web page). This can be used for some operating systems that do not have POSIX threads.

It is also possible to use another user level thread package named FSU Pthreads (see FSU Pthreads home page). This implementation is being used for the SCO port.

See the `thr_lock.c' and `thr_alarm.c' programs in the `mysys' directory for some tests/examples of these problems.

Both the server and the client need a working C++ compiler (we use gcc and have tried SparcWorks). Another compiler that is known to work is the Irix cc.

To compile only the client use ./configure --without-server.

There is currently no support for only compiling the server. Nor is it likly to be added unless someone has a good reason for it.

If you want/need to change any `Makefile' or the configure script you must get Automake and Autoconf. We have used the automake-1.2 and autoconf-2.12 distributions.

All steps needed to remake everything from the most basic files.

/bin/rm */.deps/*.P
/bin/rm -f config.cache
aclocal
autoheader
aclocal
automake
autoconf
./configure --with-debug --prefix='your installation directory'

# The makefiles generated above need GNU make 3.75 or newer.
# (called gmake below)
gmake clean all install init-db

If you run into problems with a new port, you may have to do some debugging of MySQL! 「H.1 MySQL server のデバッグ」節参照.

Note: Before you start debugging mysqld, first get the test programs mysys/thr_alarm and mysys/thr_lock to work. This will ensure that your thread installation has even a remote chance to work!

H.1 MySQL server のデバッグ

もしあなたが MySQL のとても新しいある機能を使っている場合、 --skip-new (これは全く新しい、潜在的に危険な機能を無効にします) または --safe-mode (これは問題を生じさせるかもしれない多くの最適化を無効にします) オプションで mysqld を実行させることができます。 「20.1.1 MySQL がクラッシュする場合に行うこと」節参照.

もし mysqld が起動しないようなら、 my.cnf が無いかチェックしてください。 my.cnf の引数は mysqld --print-defaults でチェックできます。 また mysqld --no-defaults ... で起動することにより、 my.cnf を無視することが可能です。

もしあるとても特殊な問題があれば、あなたは、いつも MySQL を デバッグするよう試みることができます。 これを行うには、 MySQL--with-debug オプション付きで configure しなくてはなりません。 MySQL がデバッギングを有効にしてコンパイルされているかを 知るには、 mysqld --help とします。 もし --debug フラグが リストされていればデバッグが有効です。 mysqladmin vermysqld のバージョンをリストできます。 この場合は mysql ... -debug と、バージョン番号に表示されるでしょう。

gcc か egcs の場合、推奨する configure のラインは:

CC=gcc CFLAGS="-O6" CXX=gcc CXXFLAGS="-O6 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-debug

これは libstdc++ ライブラリと C++ の例外による問題を避けることが出来るでしょう。 (many compilers have problems with C++ exceptions in threaded code).

If mysqld stops crashing when you compile it with --with-debug, you have probably found a compiler bug or a timing bug within MySQL. In this case you can try to add -g to the CFLAGS and CXXFLAGS variables above and not use --with-debug. If mysqld now dies, you can at least attach to it with gdb or use gdb on the core file to find out what happened.

もし mysqld サーバーのクラッシュを直に引き起こすことができるなら、 あなたはこのトレースファイルを作成することができます:

mysqld サーバーをトレースログファイル `/tmp/mysql.trace' オプションで起動。 このログファイルはとても大きくなります。

mysqld --debug --log

mysqld --debug=d,info,error,query,general,where:O,/tmp/mysql.trace

これは重要なタグのみを出力します。

MySQL をデバッグで configure すると、自動で多くの安全な検査関数が enable になります。 これは mysqld の状態をモニターできます。 もしそれら関数がなにか ``予期せぬこと'' を発見したら、それらを stderr に書き出します。 これは safe_mysqld が受け取って error ログに 書き出します! このことはどういうことかというと、 MySQL に予期せぬことが 起きた場合、まず最初にすべきことは、 MySQL をデバッグ有効にして configure することです! (次に、もちろん、 mysql@lists.mysql.com に メールを送り、help を聞くことです。 全てのバグレポート、MySQL のバージョンに 関連する質問は、 mysqlbug スクリプトを使用してください!)

ほとんどのシステムでは、もし mysqld がクラッシュするなら、 gdb から mysqld を起動させて多くの情報を得ることが可能です。

Linux 上でのいくつかの gdb バージョンでは、 mysqld スレッドのデバッグを可能にする場合、 run --one-thread を使用しなくてはなりません。 この場合、一度にただ一つのactiveなスレッドだけを持つことになります。

It's very hard to debug MySQL under gdb if you do a lot of new connections the whole time as gdb doesn't free the memory for old threads. You can avoid this problem by starting mysqld with -O thread_cache_size= 'max_connections +1'.

もし Linux 上で gdb 4.17.x を使用しているなら、 `.gdb' ファイルを いかにしたがって、カレントのディレクトリーにインストールすべきです:

set print sevenbit off
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
handle SIGWAITING nostop noprint
handle SIGLWP nostop noprint
handle SIGPIPE nostop
handle SIGALRM nostop
handle SIGHUP nostop
handle SIGTERM nostop noprint

If you have problems debugging threads with gdb, you should download the latest gdb snapshot and try this instead. The new gdb version has very improved thread handling!

以下は mysqld のデバッグ例です:

shell> gdb /usr/local/libexec/mysqld
gdb> run
...
back   # mysqld がクラッシュした際、これを行います
info locals
up
info locals
up
...
(until you get some information about local variables)

quit

上記の出力を、 mysqlbug で作成したメールに含み、 そして mysql@lists.mysql.com. に送ってください。

もし mysqld がハングするなら、 strace/usr/proc/bin/pstack のような システムツールを使用して mysqld がどこでハングしているか 調べることができます。

もし mysqld が CPU や メモリー を食い始めたり、``ハング'' したりするなら、 mysqladmin processlist status を使用して誰かが多くの時間のかかる クエリを実行しているか確かめることが出来ます。 パフォーマンスの問題や新しいクライアントが接続できないときの問題と もしあなたが考えるなら、 いくつかのウインドウで mysqladmin -i10 processlist status を 実行するのはよい考えでしょう。

もし mysqld が死んだりハングしたりするなら、 mysqld--log で起動すべきです。 再び mysqld が死んだら、 あなたはログファイル中の、 mysqld を kill するクエリをチェックします。 mysqld--log オプションで起動する前に、 全てのテーブルを myisamchk でチェックすべきです。 (前のクラッシュ時にテーブルが壊れているかもしれないので) 「15 Maintaining a MySQL installation」節参照.

もし mysqld --log でログファイルを使用するなら、'hostname' ログファイル、 これはデータベースディレクトリにありますが、これをチェックし、問題を引き起こすクエリ を見つけます。 mysqld が適切にインデックスを使用するのに時間がとてもかかる全ての SELECT 文を EXPLAIN で実行することを試みます。 「7.24 EXPLAIN 構文 (SELECTについての情報を得る)」節参照. また、mysql コマンドラインでは出来なかった、複雑なクエリもテストすべきです。

もしエラーログファイル(`hostname.err')中に mysqld restarted という文があるなら、 mysqld を失敗させるクエリを見つけます。 もしこれが起きるなら、myisamchk ( 「15 Maintaining a MySQL installation」節参照) で全てのテーブルをチェックし、 MySQL ログファイルにあるそのクエリをテストすべきです。 もしそのようなクエリをみつけたなら、まず最初に最新の MySQL にアップグレード してみてください。 もしそれでもだめで、かつ mysql メーリングリストの アーカイブにもなにも見つけることが出来なかったなら、 mysql@lists.mysql.com に バグレポートを出すべきです。 メーリングリストのアーカイブへのリンクは MySQL documentation page.

もし不正なテーブルをえたり、 mysqld が常にいくつかの update コマンドで 失敗するなら、以下のようにしてこのバグの再現をテストします:

mysqladmin debug コマンドは使用中のロック、使用しているメモり、 クエリの使用の情報を、mysql ログファイルにいくつかダンプします これはいくつかの問題解決に役立ちます。 このコマンドは、 MySQL を デバッグ可能でコンパイルしていなくても、いくつかの役立つ情報も提供します。

いくつかのテーブルでだんだん遅くなる問題であるなら、 OPTIMIZE TABLEmyisamchk でテーブルを修復し、最適化を試みるべきです。 遅いクエリは、 EXPLAIN でもチェックできます。 「15 Maintaining a MySQL installation」節参照.

このマニュアルの OS 固有の問題 の節も読むべきです。 「4.11 System-specific issue」節参照.

もし Perl DBI を使用しているなら、 trace メソッド、あるいはDBI_TRACE 環境変数で デバッグ情報を有効にできます。 「22.5.1.1 The DBI interface」節参照.

H.2 Debugging a MySQL client

To be able to debug a MySQL client with the integrated debug package, you should configure MySQL with --with-debug. 「4.7.3 典型的な configure オプション」節参照.

Before running a client, you should set the MYSQL_DEBUG environment variable:

shell> MYSQL_DEBUG=d:t:O,/tmp/client.trace
shell> export MYSQL_DEBUG

This causes clients to generate a trace file in `/tmp/client.trace'.

If you have problems with your own client code, you should attempt to connect to the server and run your query using a client that is known to work. Do this by running mysql in debugging mode (assuming you have compiled MySQL with debugging on):

shell> mysql --debug=d:t:O,/tmp/client.trace

This will provide useful information in case you mail a bug report. 「2.3 バグや問題を報告する方法」節参照.

If your client crashes at some 'legal' looking code, you should check that your `mysql.h' include file matches your mysql library file. A very common mistake is to use an old `mysql.h' file from an old MySQL installation with new MySQL library.

H.3 Comments about RTS threads

I have tried to use the RTS thread packages with MySQL but stumbled on the following problems:

They use old version of a lot of POSIX calls and it is very tedious to make wrappers for all functions. I am inclined to think that it would be easier to change the thread libraries to the newest POSIX specification.

Some wrappers are already written. See `mysys/my_pthread.c' for more info.

At least the following should be changed:

pthread_get_specific should use one argument. sigwait should take two arguments. A lot of functions (at least pthread_cond_wait, pthread_cond_timedwait) should return the error code on error. Now they return -1 and set errno.

Another problem is that user-level threads use the ALRM signal and this aborts a lot of functions (read, write, open...). MySQL should do a retry on interrupt on all of these but it is not that easy to verify it.

The biggest unsolved problem is the following:

To get thread-level alarms I changed `mysys/thr_alarm.c' to wait between alarms with pthread_cond_timedwait(), but this aborts with error EINTR. I tried to debug the thread library as to why this happens, but couldn't find any easy solution.

If someone wants to try MySQL with RTS threads I suggest the following:

H.4 スレッドパッケージ間の違いは何?

MySQL は使用されるスレッドパッケージに非常に依存しています。 そのため、MySQL に良いプラットフォームを選択する時には、 スレッドパッケージが非常に重要です。

少なくとも3つのタイプのスレッドパッケージがあります:

いくつかのシステムでは、カーネルスレッドは、システムライブラリ内で、 ユーザレベルスレッドの統合によって管理されます。 この場合、スレッド切替えはスレッドライブラリによってだけ行なわれ、 カーネルは実際には 'thread aware' ではありません。


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