[postfix-jp: 3816] Re: postfixadminとの組み合わせで謎の現象

[大塚 総司(OTSUKA soushi) <otsuka@xxxxxxxxxxxxxx>]

大塚です。

> つまり、RETRY_CONN_INTV 秒 (60 秒固定) の間は STATFAIL (異常) 扱いに
> します。結果、60秒間はこの MySQL セッションは使えなくなります。

そんな動きがあるんですね。
大変参考になります。

あまりソースが読めないので的外れな質問になっていたらすいません。
同ファイル内のplmysql_query()でquery実行時、クエリに失敗しても
dict_mysql_get_active()で別のセッションを探している感じですが、別のセッション
を使って再度クエリの実行をしないのでしょうか。

何となく、たまたまその時に2セッション使っていて、1つのstatがSTATFAILだと
もう一つの(正常な)セッションを使ってうまく処理できそうな気がします。
あと別のセッションがない場合は、新しくセッションを作るのですが、STATFAILに
なっているセッションが一つでもある場合だと新規セッションは行わない…という
感じでしょうか。

個人的には STATFAIL になっているセッションはRETRY_CONN_INTV(60)秒間は無視を
して、その代わり別のセッションを使うか、ない場合は新規作成して処理を続けてほ
しいなと思いました。
ただ、今度は大量にquery failedを起こすとコネクションが量産されますが、他の
関係ないメールキューも巻き込んでエラーになるよりかはこっちの方がいい気がしま
す。
(すいません、あまりデメリットを考えきれてないです)

> 問題の回避方法ですが、src/global/dict_mysql.c の
> 「mlmysql_down_host(host);」を「mlmysql_close_host(host);」に
> 書き換えれば即座に有効になって再接続されますが、MySQL サーバーを
> 複数立てていて Postfix からそれらを参照しており、MySQL サーバーの
> フェイルオーバーを期待したい場合にうまい具合に動作しなくなると
> 思われます。

回避方法もありがとうございます。
今回はpostfixadminが作るtable調整で回避したので、とりあえずソースの修正は
なしでいこうと思います。

> MySQL に詳しくないのですが、plmysql_connect_single() 内の
> mysql_real_connect() の成功後に「mysql_set_character_set(host->db, "binary");」
> を追加すると回避できないでしょうか?

dict_mysql_quote()の中でmysql_real_escape_string()使っているので、文字コード
の指定が適当だと変にエスケープされる可能性があります。
と、思ったのですがSELECT文しか実行しないし、そもそもfromやtoに全角文字列が含
まれている時点でそれはおかしなメールなので、変にエスケープされてもよしと考え
てもいいかもしれませんね…。

ただ、確認はしてみたいので、後日エラーが出ないか検証してみます。
(今、いじれる環境がないので少し時間がかかると思います)

> > また、SQLクエリログも一緒に付けています。
> > クエリログでは一応、test4@mail.msrv.dev.example.jpをselectしたクエリが残って
> > います。
> 
> クエリは発生しないはずなんですが、何か見落しているのかなぁ。

ログを見ると違うセッションがクエリを実行してるみたいです。
もしかしたら僕のログの取り違えかもしれないので、再度検証してみます。

以上です。

---------------------
  大塚 総司(OTSUKA soushi) <otsuka@xxxxxxxxxxxxxx>

_______________________________________________
Postfix-jp-list mailing list
Postfix-jp-list@xxxxxxxxxxxxxxxxxxxx
http://lists.sourceforge.jp/mailman/listinfo/postfix-jp-list