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! 「G.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!
もしあなたが MySQL のとても新しいある機能を使っている場合、
--skip-new
(これは全く新しい、潜在的に危険な機能を無効にします)
または --safe-mode
(これは問題を生じさせるかもしれない多くの最適化を無効にします)
オプションで mysqld を実行させることができます。
「18.0.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 ver
も
mysqld
のバージョンをリストできます。 この場合は
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++ の例外による問題を避けることが出来るでしょう。
もし 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なスレッドだけを持つことになります。
もし 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
以下は 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
でチェックすべきです。
(前のクラッシュ時にテーブルが壊れているかもしれないので)
「13 Maintaining a MySQL installation」節参照.
もし mysqld --log
でログファイルを使用するなら、'hostname' ログファイル、
これはデータベースディレクトリにありますが、これをチェックし、問題を引き起こすクエリ
を見つけます。
mysqld が適切にインデックスを使用するのに時間がとてもかかる全ての SELECT
文を
EXPLAIN
で実行することを試みます。 「7.22 EXPLAIN
構文 (SELECT
についての情報を得る)」節参照.
また、mysql
コマンドラインでは出来なかった、複雑なクエリもテストすべきです。
もしエラーログファイル(`hostname.err')中に mysqld restarted
という文があるなら、
mysqld
を失敗させるクエリを見つけます。
もしこれが起きるなら、myisamchk
( 「13 Maintaining a MySQL installation」節参照) で全てのテーブルをチェックし、
MySQL ログファイルにあるそのクエリをテストすべきです。
もしそのようなクエリをみつけたなら、まず最初に最新の MySQL にアップグレード
してみてください。 もしそれでもだめで、かつ mysql
メーリングリストの
アーカイブにもなにも見つけることが出来なかったなら、 mysql@lists.mysql.com に
バグレポートを出すべきです。 メーリングリストのアーカイブへのリンクは
MySQL documentation page.
もし不正なテーブルをえたり、 mysqld
が常にいくつかの update コマンドで
失敗するなら、以下のようにしてこのバグの再現をテストします:
mysqladmin shutdown
で)
myisamchk -s database/*.MYI
で全テーブルをチェック.
myisamchk -r database/table.MYI
で悪いテーブルを修正。
mysqld
を --log-update
でスタート
mysqld server
を停止。
mysqld
server を --log-update
なしで 起動。
mysql < update-log
で再実行。 update log は
MySQL データベースディレクトリに
your-hostname.#
という名前で保存されています。
ISAM
コード中の
再現可能なバグを見つけたことになります!
このテーブルと update log を ftp://www.mysql.com/pub/mysql/secret に
FTP で put します。 われわれはこれをできる限り速く修正します!
mysqladmin debug
コマンドは使用中のロック、使用しているメモり、
クエリの使用の情報を、mysql ログファイルにいくつかダンプします
これはいくつかの問題解決に役立ちます。 このコマンドは、 MySQL を
デバッグ可能でコンパイルしていなくても、いくつかの役立つ情報も提供します。
いくつかのテーブルでだんだん遅くなる問題であるなら、 OPTIMIZE TABLE
か
myisamchk
でテーブルを修復し、最適化を試みるべきです。
遅いクエリは、 EXPLAIN
でもチェックできます。
「13 Maintaining a MySQL installation」節参照.
このマニュアルの OS 固有の問題 の節も読むべきです。 「4.11 System-specific issue」節参照.
もし Perl DBI
を使用しているなら、
trace
メソッド、あるいはDBI_TRACE
環境変数で
デバッグ情報を有効にできます。
「20.5.1.1 The DBI
interface」節参照.
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.
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:
-DHAVE_rts_threads
.
thr_alarm
.
thr_alarm
. If it runs without any ``warning'', ``error'' or aborted
messages, you are on the right track. Here follows a successful run on
Solaris:
Main thread: 1 Tread 0 (5) started Thread: 5 Waiting process_alarm Tread 1 (6) started Thread: 6 Waiting process_alarm process_alarm thread_alarm Thread: 6 Slept for 1 (1) sec Thread: 6 Waiting process_alarm process_alarm thread_alarm Thread: 6 Slept for 2 (2) sec Thread: 6 Simulation of no alarm needed Thread: 6 Slept for 0 (3) sec Thread: 6 Waiting process_alarm process_alarm thread_alarm Thread: 6 Slept for 4 (4) sec Thread: 6 Waiting process_alarm thread_alarm Thread: 5 Slept for 10 (10) sec Thread: 5 Waiting process_alarm process_alarm thread_alarm Thread: 6 Slept for 5 (5) sec Thread: 6 Waiting process_alarm process_alarm ... thread_alarm Thread: 5 Slept for 0 (1) sec end
MySQL is very dependent on the thread package used. So when choosing a good platform for MySQL, the thread package is very important.
There are at least three types of thread packages:
ps
may show the different threads. If one thread aborts the
whole process aborts. Most system calls are thread-safe and should
require very little overhead. Solaris, HP-UX, AIX and OSF1 have kernel
threads.
In some systems kernel threads are managed by integrating user level threads in the system libraries. In such cases, the thread switching can only be done by the thread library and the kernel isn't really ``thread aware''.
Go to the first, previous, next, last section, table of contents.