データベースやWebサーバーは、実際に稼働してから問題が多発します。
データ量が増えてきたり、アクセスが増えてきたらまずレスポンスの問題が発生するでしょう。
経験のあるエンジニアがいれば、十分なテストを行ってから稼働するわけですが、なかなかそうもいきません。
今回のテーマはMySQLのwait_timeoutの設定です。
なぜハマってしまうかというと、グローバル変数のwait_timeoutがそのまま個々のセッションのwait_timeoutになるとは限らないからです。
結論からいいますと、
が、セッション変数のwait_timeout に反映されます。
そして、どちらが反映されるかは、mysqlのAPI呼出し時に対話型クライアントの定義かどうかできまります。
MySQLサーバーと、サーバ接続を開始するAPI、mysql_real_connect() を呼び出す際、
CLIENT_INTERACTIVE オプションを指定したものが対話型でinteractive_timeout を使用します。
それ以外はwait_timeout がそのままセッション変数のwait_timeoutとなります。
つまり、MySQLと接続するアプリケーションの実装方法によるわけです。
いくらMySQL QueryBrowserのwait_timeoutを確認しても、
問題となっているアプリは別の実装をしてinteractive_timeoutを使用している可能性があります。
結果として、セッション変数のwait_timeout はそのままアイドル状態で破棄されるまでの時間になりますが、
セッション変数のinteractive_timeoutは、実際には使用されません。
注意①
SET GLOBAL で設定したときは、
my.confの設定に追加するのを忘れないようにして下さい。
データベースを再起動すると、デフォルト値に戻ってしまいます。
注意②
容易に想像ができると思いますが、
set global session wait_timeout=5;
でグローバル変数を変更しても、そのセッション変数は変更されないので注意が必要です。
グローバル変数を変更して変更されるのは、その後の新いセッションに対してです。
注意③
あまりwait_timeouを短くしてしまうと、バッチ処理ではタイムアウトが発生する可能性があります。
逆に、APIサーバー等で一瞬の処理を行うにも関わらず、セッションが残ってしまうとtoo many connection
のエラーが発生します。
注意④
デフォルトのinteractive_timeoutとwait_timeoutは同じ値が設定されています。
要するに、この設定の使い方を知らなければ２つ設定がある意味はありません・・・。
MySQLの設定は、あんまり多くありませんし、Webで資料もたくさん見つかります。
が、実際に問題に直面しないとなかなか注意が行き届かないんですよね・・・。
