[pgpool-general-jp: 1367] Re: エラー時に無応答のケースについて

Yugo Nagata nagata @ sraoss.co.jp
2015年 3月 27日 (金) 19:23:10 JST


近藤さん

長田です。

時間がかかってしまいすみません。

近藤さんの解析の通り、トランザクション内でエラーを起こすための
無効クエリの送り先が master 以外となっていたのが原因でした。

pgpool-II は無効クエリを送った後に、全てのバックエンドからの
応答を待ちますが、マスターからの応答が無かったために、永遠に
待ち続けるハングとなっていました。

修正パッチを添付いたしますので、よろしかったら試してください。

この修正では、無効クエリの送り先を
「元の SELECT クエリでエラーが起こったノード以外の全て」
に送るようになっています。これにより、マスター以外でエラーが
発生した場合にはマスターに無効クエリが発行されます。

確認のため、下のクエリを 100 回送信するテストを行いましたが、
単純問い合わせ、拡張問い合わせの両方でハングすることはありませんでした。

BEGIN;
SELECT 1 FROM not_existing_table;
END;

On Thu, 26 Mar 2015 23:07:12 +0900
近藤 <skond66 @ gmail.com> wrote:

> お世話になっております。調査は難航中なのでしょうか?
> レプリケーションモードかつロードバランスの使用者は極めて少ないかもしれませんが、一応、こちらのとった対策を投稿しておきます。
> 
> この不具合は、これが起因となって、高負荷時や、開発時などSQLエラーが混じった状況で、クライアントへの応答がフリーズし、バックエンドへの接続が
> idle in transaction のまま残り続け、システムの安定稼働を阻害します。
> 
> こちらは以下の2点の修正をソースに加えることで、過去の2.2系統と同様の動作かつ安定稼働が可能となっております。
> 
> 1.明示的なトランザクション内の select を、全ノードに送付するように変更
> 2.トランザクション内でのselect
> エラー発生時、1の変更により全てのノードに同じselectが送られているため、他のノードへエラーを発生させる処理は不要。バイパスするように変更。
> 
> 
> 当初、replicate_select をONにして新バージョンに対応しようとしましたが、以下の2点で断念しました。
> 
> 1.psql で、 \d  がエラーになりがちで使いづらい。(\d も常に両方のノードに送られてしまい、oid が異なっているとエラーとなるため。)
> 
> 2.常に select処理が両方のノードに送られるため、パフォーマンスが半分になってしまう。
> 
> 
> 以上


-- 
Yugo Nagata <nagata @ sraoss.co.jp>
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: pool_proto_modules.patch
型:         text/x-diff
サイズ:     835 バイト
説明:       無し
URL:        <http://www.sraoss.jp/pipermail/pgpool-general-jp/attachments/20150327/9e541cfb/attachment-0001.bin>


pgpool-general-jp メーリングリストの案内