[pgsql-jp: 35286] Re: pgpoolのreplication_stop_on_mismatch について

[Tsunehisa Kazawa]

こんばんは。加澤です。

Tatsuo Ishii wrote:
> ここでの肝は，masterのSELECTが取得したロックがsecondryのSELECTが完了す
> るまで解放されないことです．ですから，ACCESS SHAREを発行するのではなく，
> SELECTを明示的なトランザクションブロックの中に入れるだけでよいと思いま
> す．

石井さんのおっしゃるとおり、SELECT を明示的なトランザクションブロックに
含めるだけでトランザクション終了まで ACCESS SHARE ロックが確保されたまま
となるようになり、目的通りの動作とすることが出来ました。どうもありがとう
ございます。

// 僕のロックに関する知識が足りませんでした。すみません。

ちなみに今回も、最終的には目的の動作をさせることが出来るようになったので
すが、当初「更新時の ACCESS EXCLUSICE ロック＆参照時の ACCESS SHARE ロッ
ク」対応コードを入れたとたん、deadlock が多発してしまって難儀しました。
更新時のロック順序はそれなりに意識していたんですが、参照時はほとんど意識
していなかったため典型的な deadlock のパターンにはまり込んでしまいまし
た…。コード全体を見直し長いトランザクションでのロック順序を厳密に守るよ
うにして何とか解決。

// そういえば複数のテーブルを join している場合のロック
// 確保順序ってどうなっているのでしょうか？
// 今回はよく分からなかったのでそういう SQL の前に明示的
// に LOCK TABLE 〜 IN ACCESS SHARE MODE しちゃいました。


> この問題が結構解決が難しくて，仮に2PC(2 phase commit)が導入されても解
> 決されません．たぶんshared nothing方式のクラスタの宿命ではないかと思い
> ます．

そうなんですね。勉強になりました。
僕のように HA を目的として pgpool を使う人もそれなりにいるのではないかと
思いますが、そのような構成でちゃんと動かすためには結構アプリケーション側
のケアが必要なのですね。


>>>上記のような現象が起こるのは絶妙なタイミング時に限ったことなので、例えば
>>>普段は load_balance_mode = true とか replication_stop_on_mismatch =
>>>false で運用すれば良いじゃないか、というご意見もあるかもしれません。
>>>
>>>ただ例えば、「まるごと！PostgreSQL」で石井さんのご紹介されている、フロン
>>>ト側の pgpool の動作するサーバを複数用意したような構成においては、何らか
>>>の原因で１つの pgpool が縮退してしまった場合、他の pgpool はデータ件数不
>>>一致という形でしかそのことを知るすべがありません (もちろん、pgpool の外
>>>側に「ログ監視→他の pgpool を明示的に switch」といった動作を行う監視プロ
>>>グラムを作る、ということは可能ですが…)。
> 
> pgpool同士でハードビートや情報交換ができるようにすれば解決できると思う
> のですが...

おっしゃるとおりですね。
でも、そうやってどんどん機能を入れていってしまうとせっかくの今の pgpool
のシンプルさが失われてしまいそうだったりして、その辺のさじ加減はなかなか
難しいところでしょうか。ハートビート交換くらいならばそれほど難しくならな
いのかな…。

それではまた。いつもどうもありがとうございます。

-- 
  ◇   加澤恒央 Tsunehisa KAZAWA
◇  ◇ mailto:kazawa ＠ ca2.so-net.ne.jp
  ◇   http://www.digitune.org/