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

[Tatsuo Ishii]

石井です．

> 山崎です。
> 毎回、遅いレスで申し訳ございません。
> 
> > それはしょうがないですね．replication_strict = trueの場合，master側の
> > SELECTが完了するのを待ってからsecondary側にSELECTを投げるので，SELECT
> > の重さに比例して時間のずれは発生します．
> 確かにやむをえないかと思いました。
> 
> > 上記2点はデータの同一性の保障，という点とは無関係だと思います．どちら
> > かというと，デッドロックが気になりますね．
> 確かにデータの同一性とは無関係でした。紛らわしくて申し訳ございません。
> あくまで今回の現象の回避策として、という事でした。
> デッドロックは実際に検証／運用してみて発生率を測ってみた上で
> 許容範囲かどうか見極めることにしたいと思います。
> 
> > pgpoolでは無理ですが，pgpool-IIなら3ノード以上をサポートしているので，
> > ノード数を奇数にしておけば，データが不一致になったときに多数決でどれを
> > 落とすかを決められます．まだそういう機能はpgpool-IIにはありませんが，
> > 原理的にはその方向で実装可能です．
> > 
> > もちろんこれでも勝った方のノードのデータが正しい，という保障は無いので
> > すが，そこまでコンピュータに求めるのは無理でしょう．最終的には人間が判
> > 断すべきことと思います．
> 確かに人間の判断すべき部分だと思います。
> 今回のケースでもmaster/secondaryの両方にSELECTを投げて結果を比較する事に
> 簡易のチェック機能を求めていた部分もあるのですが、冷静に考えますと
> 複数のトランザクションが並列処理されている状況で瞬間的な検索結果を
> 比較することには意味が無いと思えてきました。
> 
> ご提案頂いた多数決による方法もオプションとして選択肢が増えることは
> ユーザーとして有り難いのですが、pgpoolが使われている現場でのニーズが
> どれほどあるか、を考えますとあまり優先的に実装を希望してよい項目でも
> ないのでは、という思いもあります。
> 
> > そうですね．というか，こう(「トランザクション全てが無事に実行完了すれ
> > ば，データは同一であろう」という立場)でないレプリケーションソフトとい
> > うのはあるんでしょうか？
> 他のレプリケーションツールの実装についてもあまり詳しくない為、
> あまり的を得ていない発言で申し訳ございませんでした。
> ファイルシステムレベルで同期を取るような方式等を勝手に想像しておりましたが
> そういう種類のものはRDBMSの同期ツールというよりはOSレベルに近いものに
> なってしまいますよね。
> 
> > > 現状、パフォーマンスも若干悪いという面もあるので、
> > > load_balance_mode が問題なさそうであれば採用したいと考えています。
> > > 
> > > あるいはpgpoolそのものにmaster/secondary間のデータの同一性を監視するような
> > > 機能を設ける予定など、ありますでしょうか？
> > 
> > まず「同一性とは何か」という定義が必要です．RDBでは，テーブル内の行の
> > 並びは意味を持たないことになっているので，行を並び換えれば同じものにな
> > るのであれば，それは同じである，という解釈だとすると，そのことをリアル
> > タイムで検証するのは容易ではありません．
> 
> たしかに監視出来たとしても、その監視機能に重点的にCPUなどのリソースが
> 奪われてしまうようでは本末転倒でしょうし、よほど考えて設定しないと
> エラー(同一でない)判定が大量に上がってきてノイズにしかならないのかも
> しれません。
> 
> > > (そういう機能を期待するならPGClusterなどを使うべき、というご意見も
> > >  あるのかもしれませんが)
> > 
> > 私の理解では，PGClusterでもそのあたりの事情は同じです．
> > 
> > 1) 各ノードのデータが瞬間的にずれていることはあり得る
> > 
> > 2) 各ノードのデータが同一であるかどうかは検証していない
> > 
> > 私の知る限り，pgpool，PGCluster，Slony-Iなど，すべてこのあたりの事情は
> > 同じです．
> 
> PGClusterについての知識不足で失礼いたしました。
> 
> > 1)を防止するためには，各ノードの更新がすべて完了するまではそのデータを
> > 見せない，という仕掛けが必要です．一番簡単なのは，まず排他ロックを取り，
> > それから処理に入る方法ですが，これでは致命的にパフォーマンスが阻害され
> > ます．pgpoolでは，PGClusterと違ってすべての更新処理を直列化するのでは
> > なく，並列処理も許すことによってパフォーマンスを上げてますから，このメ
> > リットがなくなってしまうのは痛い...なかなか難しい問題です．
> 
> 実運用のレベルとしては、データの厳密性よりもパフォーマンスを重視したいなら
> 並列処理化を進めて、秒レベルの結果のズレは運用でカバーしてもらう、で十分という
> 事が多いかと思います。逆に厳密なデータを求められているのであれば、
> なるべく処理は直列化にした「安全設計」でCPU性能やメモリ容量といった投資で
> パフォーマンスを稼ぐべき、というのが簡単な解決方法かもしれませんので。
> 
> いずれにせよ、利点も欠点も理解した上でシステムに適合するのかどうか
> 判断すべき、という事を再認識いたしました。
> 
> > 全然話は変わりますが，こういうpgpoolへの疑問，あるいはpgpoolへのリクエ
> > ストなどについて気軽に語り合うような場があったら参加したい，という方は
> > いらっしゃいますか？まずはセミナーまでいかないような，勉強会位の規模の
> > ものを想定しています．
> 
> 私としてはそのような場があれば是非参加させて頂きたいと思います。
> 
> よろしくおねがいします。

御賛同いただきありがとうございます．
年内はちょっと時間が取れないのですが，年が明けたら開催したいと思います．
開催時間は平日の夕方位からでよろしいでしょうか?

開催場所は，弊社内の会議室(本当に狭くて申し訳ないのですが)で行うことに
なると思います．最寄駅はJRの大塚駅になります(徒歩5分)．
地図は http://www.sraoss.co.jp/company/access.php で御覧いただけます．

開催日などについては決まり次第このMLで御連絡いたします．
--
Tatsuo Ishii
SRA OSS, Inc. Japan