[pgcluster: 906] Re: pgbench で固まってしまいます

[Eiichiro ITANI]

猪谷です。日本からこんばんわ (^^)

a.mitani ＠ sra-europe.com writes:

> これはレプリケーションサーバではなく，クラスタDBが固まった時に見られる症状の
> ように思います．

なるほど…
少し理解を整理したいので、よろしければ御指導いただけますでしょうか。

どこかのクライアントがなかなか完了しないトランザンクションを開始してし
まうと、それとはまったく関係ないテーブルやデータベースクラスタに対する
更新をかけようとするクライアントも、レプリケーションの為にブロックされ
る、という状況が発生する、と考えてもよろしいのでしょうか? 例えば…

クライアント1(c1):
  BEGIN;
  INSERT INTO t1 VALUES (?);
//  sleep 100; トランザンクション中になんかをじっくりやってる。
  COMMIT;

クライアント1'(c1'):
// sleep 3; ちょっと待ってからトランザンクション開始
  BEGIN;
  INSERT INTO t1 VALUES (?);
  COMMIT;

クライアント2(c2):
// sleep 5; 微妙に待ってから開始
  BEGIN;
  INSERT INTO t2 VALUES (?);
  COMMIT;

# t1、t2 は独立しており、関係従属性はないものとします。

3つのクライアントが同時に並行して上のようなクエリを投げた場合、

1) c1が t1 のロックを獲得、このトランザンクション実行
2) c1' は t1 の更新をしようとするが、c1の完了待ちでブロック
3) c2 は c1の同期が完了しないため、レプリケータにより更新がブロックさ
  れ、レプリケーション完了待ち
4) c1がようやく完了、c1の更新が同期
5) c1' あるいは c2 のいずれかが実行されるが、この同期が完了するまでも
  う一方は相変わらず待ち
6) 最後までブロックされていたトランザンクションが実行され、同期完了

という具合に、postgresql のレベル、レプリケータのレベル、の2層でブロッ
クが発生する可能性がある、のでしょうか。

だとすると fastCGI などでプロセスが永続化する場合、クライアントのプログ
ラムミスなどで(トランザンクションが後始末されないまま)DB接続が生き残っ
てしまうと、上のようなことが起きてpgcluster の全体に対する更新がブロッ
クされてしまう、かも。

まさにそういう状況であったのかな…?


>> ところで、レプリケータのカスケード設定なんですが、これは主レプリケータ
>> の pgreplicate.conf に、Replcate_Server_Infoを書く物なのでしょうか。コ
>> メントを読むとどっちにも取れる(カスケード上位ならば設定を書く | カスケー
>> ド上位サーバの場所を書く)ので、混乱していました。
>
> 上位のレプリケーションサーバと接続するための情報ですので，
> 上位のレプリケーションサーバの情報を書いてください．

ありがとうございます。そのように致します。

--
  いたに えいいちろう