[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 メーリングリストの案内