[pgcluster: 48] Re: 次の追加機能案

[TANIDA Yutaka]

谷田です。

On Thu, 22 Jan 2004 14:40:31 +0900
mitani <mitani ＠ sraw.co.jp> wrote:

> > 同時に競合する問い合わせがきたらどうなりますか？今はレプリケーションサー
> > バーが同時に１台しか機能してないので、そこで帳尻を合わせる事も出来ますが
> > ・・・
> レプリケーションサーバをカスケードしても，処理は仮想キューに入りますので，
> 今回のロック競合回避と同じことができます．

えっと、理解のために確認させてください。

A,B,C...というレプリケーションサーバーがあり、おのおのにA1,A2...An,B1...Bn...
というクラスタサーバーがぶら下がっているとします。クラスタとレプリケーショ
ンサーバーの組はA群、B群と呼ぶ事にします。

クラスタサーバーであるAn,Bn,Cnは、すべて同じデータを共有するんですよね？

で、そのリクエストは[pgcluster:45]の図を見ると、カスケードをたどって各レ
プリケーションサーバーで処理される、と。
・
となると、仮想キューで処理が全部出来るのは、それはこの場合すべての問い合
わせが結局Aの仮想キュー上に乗って、それから処理されているという事ですか？

もしそうだとしたら、最初からすべてAがレプリケーション要求を受ければわざ
わざカスケードにする意味は何もないような・・・

> カスケードの良いところは，レプリケーションサーバを動的に追加できることだ
> けでなく，冗長性を持たせるための待機系のレプリケーションサーバを遊ばせる
> ことなく，有効に利用でき，レプリケーションサーバの負荷を分散できるところ
> です．

結局負荷分散になってないような気がします・・・

レスポンスモードの話はむしろ面白くて、パフォーマンスの影響を避けるように
設定しつつ、複数のクラスタ群の更新分野を完全に分ける（データベースが別と
か）ことで相互バックアップが可能になりそうですね。

# それをするのにいったい何台マシンが必要なんだ、と考えると怖くて夜も
# 眠れません

> > そうすれば、動的にマシンを追加できるソリューションの完成です:-)
> 確かに，そういう使い方もありえますね．
> システム構成が自由自在！　面白いけど．．．

本当にこれだけ出来たら、Oracle RACに対抗できるかもしれませんね。PGgridと
でも名付けますか:-)

-- 
TANIDA Yutaka <tanida ＠ sra.co.jp>