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

[Tatsuo Ishii]

石井です．

> 加澤です。メールを出した後気が付きました。
> 
> Tsunehisa Kazawa wrote:
> > Tatsuo Ishii wrote:
> >>もしかして load_balance_mode がtrueになっていますか？それだとどちらか
> >>のサーバにしか問い合わせを発行しませんから，結果の照合ができず，エラー
> >>の検出はできません．
> > 
> > この一連のスレッドは大変ためになりました。
> > 僕もこれまで load_balance_mode = true でテストしていたのですが、データ保
> > 全を考え false にしてみることにしました。
> > 
> > ＊＊＊
> > 
> > ところで false に変えてテストを開始してみたところいきなり mismatch で縮
> > 退してしまい、あぁ、実は不整合していたのだな、ということが分かったのです
> > が、その後リカバリ処理をして再びテストをしていると、この設定(※)ですと
> > insert と select が入り乱れる状況ではかなりの頻度で縮退してしまうことが
> > 分かりました。
> > 
> > ※
> > replication_mode = true
> > replication_strict = true
> > load_balance_mode = false
> > replication_stop_on_mismatch = true
> > 
> > 
> > たぶん、下記のような状況なのではないかと想像しました。
> > 
> >      trans.1             trans.2
> > primary secondary   primary secondary
> >    :        ;
> > insert      :
> >             :       select
> >             :                select
> >          insert
> >                              ↑データ件数不一致で縮退！
> > 
> > // 上の insert はもちろん実際には insert/commit です。
> > 
> > insert と select は互いに競合しないので、strict モードであったとしてもタ
> > イミング次第で上のような状況が起こりうる気がします。縮退時エラーメッセー
> > ジの kind も 'C'(CommandComplete) と 'D'(DataRow) です。
> > 
> > そこで、データ件数を変化させうる insert/update/delete を含むトランザク
> > ション全てで、対象テーブルの ACCESS EXCLUSIVE ロックを取得するようにして
> > みました。僕の理解では、strict モードにおいては、まず primary 側 lock
> > table、secondary 側 lock table が指示され (この時点で select もブロック
> > される)、その後 primary 側 insert、secondary 側 insert、primary 側
> > commit、secondary 側 commit がそれぞれ厳密な順序で実行されると考え、これ
> > で解決、と思ったのですが…。
> > 
> > その後、再び insert/select 入り乱れるテストを実行してみると、やはり縮退
> > が発生してしまいました。
> > 
> > なお、pgpool を DEBUG モードにして厳密な動作を確認しようとしてみました
> > が、DEBUG モードだとなかなか縮退させられず、今のところデータは取れていま
> > せん。
> > 
> > 上記僕の想定はどこがおかしいのでしょうか？上記以外にもデータ件数不一致を
> > 引き起こす要因があったりするのでしょうか？
> 
> もう一つ可能性を思いつきました。
> 
>      trans.1             trans.2
> primary secondary   primary secondary
>                       :        :
> select                :        :
>                     insert     :
>                              insert
>          select
>          ↑データ件数不一致で縮退！
> 
> select で獲得される ACCESS SHARE ロックは SELECT 文実行中にしか確保され
> ていませんから、primary と secondary の実行の間に insert (とそれに伴う
> ACCESS EXCLUSIVE LOCK) が入り込む余地があるわけです。
> 
> select 側で明示的に ACCESS SHARE ロックを確保するようにしたら改善しそう
> な気がしてきました。週明けにでもまたテストしてみます。

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

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

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

pgpool同士でハードビートや情報交換ができるようにすれば解決できると思う
のですが...
--
Tatsuo Ishii