[pgpool-general-jp: 57] Re: pgpoolの縮退運転について

[ktj ＠ mrj.biglobe.ne.jp]

石井さん

山崎と申します。
返答が遅れ、申し訳ございません。

> > 最近は、同時接続ユーザ数が多い場合に並列実行されるトランザクションの中で
> > 瞬間的に発生したmaster/secondary間のデータ不一致状態にSELECTを実行してしまう
> > ケースがあるのでは？とも考え始めました。
> > (pgpoolの利用を前提に作られたアプリではないので、log_statementによるSQLの
> >  記録を見る限りは、明示的なロックなどは入っていないように思われるので。)
> 
> その可能性はあります．
> 
> なので，load_balance_mode = off のときは，masterにだけSELECTを発行(現
> 在はsecondryにもSELECTを投げている)するようにしたらどうかな，と思って
> います．ただ，副作用のあるSELECTが来る可能性があるので，コメントかスイッ
> チで動作を選べるようにした方がよいかもしれません．

先程の浅羽さんへの返信に書かせて頂いた通り、一部の重いSELECT文において
master側とsecondary側のログの記録が8秒もずれている事がありましたので、
いっそのこと、
 ・load_balance_mode = on にして、検索系クエリは片側にしか投げないようにする
 ・replication_strict = false にしてmasterからの実行結果を待たずに並列処理させる
のいずれかの方法を取るしかないか、とも考えております。

ただ、上記の仕様に変更した場合にmaster/secondaryのデータ同一性がきちんと
保証されるだろうか、という点を危惧しております。

現状でも100％安全とは思っていないのですが、master/secondaryの両方に
SELECT文を発行し、差異がある場合は縮退させる事で被害が拡大することは
防止できるという点では、それなりに保全性は高いと考えています。
(ただ、この場合でも差異が出ていたmaster側のデータが信頼されるべき値で
 あった場合、縮退してしまうとそのデータそのものは不正な状態で残ってしまう、
 という認識ですが)

並列処理されるトランザクション全てが無事に実行完了すれば、
master/secondaryのデータ同一性は問題ないだろう、という楽観的見方においては
瞬間的に差異が出る事を無視しても、実務上は問題ないレベルで運用できるだろう、
というのが落とし所なのかもしれませんけれども。

現状、パフォーマンスも若干悪いという面もあるので、
load_balance_mode が問題なさそうであれば採用したいと考えています。

あるいはpgpoolそのものにmaster/secondary間のデータの同一性を監視するような
機能を設ける予定など、ありますでしょうか？
(そういう機能を期待するならPGClusterなどを使うべき、というご意見も
 あるのかもしれませんが)

よろしくおねがいいたします。