[pgcluster: 274] Re: 突然１台のクラスターが落ちているケースではアップデートが非常に遅くなります。

[mitani]

三谷＠広島です．

> 三谷さんのお作りになった以下の文書
> http://www.postgresql.jp/misc/seminar/2003-05-17/B4_mitani.pdf
> を見ると１つのクラスター（マスター）のクエリーの結果が得られた時点でクエ
> リー受信をしたクラスターに対して結果を返すような話になっているのですが、
> （現在のpgcluster実装も同方式をとっていることを前提として）１つのクエリー
> が完了できないと次のクエリーが処理出来ないようになっているということなの
> でしょうか？
現在のものはレスポンス・モードを指定する機能を入れたことで，作りが変わっ
ています．
＜現在想定しているレスポンス・モード＞
(1)マスタDBのレスポンスを返すfast mode,
(2)クエリを受信したCluster DBの処理を返すnormal mode,
(3)全てのCluster DBの処理が終了するのを待って応答を返すreliable mode

当初はfast modeのみで動かしていましたが，現在デフォルトをnormal modeとし
ています．まだreliable modeは機能していませんが，仕掛け自体は大体入って
います．次版でreliable modeを実装する予定です．
fast modeについては，ディスクをNASのようなもので共有し，OracleのRACのよ
うな形態であればデータ整合性に問題なくパフォーマンスの向上が期待できると
思っています（色々制限は付くと思いますが）．その改良のため，fast modeの
実装にはもう少し時間がかかります．

> 　クエリーを投げて帰ってこないのが、「遅いから」なのか「死んでいる」から
> なのか解らない時点ではその判断時間がある程度必要かとは思うのですが、その
> 判断時間内にはその次のクエリー結果もクエリーを受け取ったクラスターに返さ
> ないというのはちょっと変な感じがします。もっとシビアに切り離しても良いと
> 思います。
多分，次のクエリーでも当該Cluster DBからの応答が返ってこないため，遅くなっ
ているのだと思います．

対策としては，LANが抜けているとか電源が落ちている状態でもCluster DBの異
常が検知できれば良いので，ウォッチドッグのようなものが必要になると思って
います．
今作りかけのreplication commit log（仮称）が出来たら，ライフチェック機能
に手を付けたいと思います．

6月のカンファレンスに間に合うと良いのですが．．．

=============================
三谷　篤<mitani ＠ sraw.co.jp>
=============================