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

[mitani]

三谷＠広島です．

> > Cluster C3 -> Replication C
> >               Replication B
> >               Replication A -> Cluster A1
> >               Replication B -> Cluster B1
> >               Replication C -> Cluster C1
> > と流れます．
> (一部編集)
> 
> # 重そう・・・更新系パフォーマンスの劣化が気になりますね。
確かに重いでしょうね．
なので，レスポンスのモードを3種類用意する必要があると思いました．

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

> 障害が発生したときに、カスケード側も落ちたらどうなるのでしょう？現行の場
> 合は、少なくともリストにある１台が生きていれば救う事が出来ますが、これだ
> とリンクが切れた時点で終わってしまうような気がします。
レプリケーションサーバの監視はクラスタサーバにやらせようと思っています．
（今もそうなっています）
で，レプリケーションサーバの「肩代わり要求」はクラスタサーバが出します．

> 例:
> ()は稼働中のレプリケーションサーバー。
> アルファベット大文字は起動中、小文字は障害発生中。
> 
> (A)-B-C -> (a)-B-C -> a-(B)-C 引き継ぎ可能
> (A)-B-C -> (a)-b-C -> ?
この場合，A群のクラスタサーバはAの障害を検知し，Bに肩代わり要求を出しま
す．で，Bも障害発生しているので，次のCに肩代わり要求を出すことになります．
B群のクラスタサーバも同様です．

> もし、これを避けるために全レプリケーションサーバーのリストを持つのであれ
> ば、今度はカスケードにする意味がないんじゃ無かろうかという気がします。
障害時の対応が必要な場合，「クラスタサーバの処理順」と「レプリケーション
サーバのカスケード順」はどこかで持っている必要がありますね．
今のところ，「クラスタサーバの処理順」はレプリケーションサーバに，
「レプリケーションサーバのカスケード順」はクラスタサーバに持たせようと思っ
ています．

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

> また、この方法で複数のレプリケーションサーバーの接続をサポート出来るなら、
> １クラスタ１レプリケーションサーバーとしてしまうことでクラスタの動的追加
> が可能になってしまうような気がします。そうなってしまうのならいっそレプリ
> ケーションサーバーは無くしてしまった方がいいんじゃないかと思います。
サーバ機能という意味では，レプリケーションサーバは必須です．
物理的には，クラスタサーバとレプリケーションサーバを同居できるようにすれ
ばレプリケーションサーバを別途立てることは不要にできますね．

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


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