JGroupsのドキュメント(http://www.jgroups.org/manual/html/index.html)では、FDディスカバリプロトコルが使用されている場合、クラスタのノードが停止したときに現在のグループコーディネータがクラスタビューを更新するグループコーディネーター自身が死亡したときに何が行われているかのドキュメンテーション。
たとえば、クラスター{A、B、C、D}を持ち、ノードAはここでコーディネーターです。 新しいメンバー 'E'が参加したい場合、コーディネーターはJOINプロトコルを開始し、Eがクラスターに参加することを許可します。メンバー 'C'がクラッシュした場合、 'C'の隣人は疑わしいメッセージをブロードキャストし、コーディネーターのGMSプロトコルは「C」を除外し、新しいビューをクラスターのメンバーにブロードキャストします。これは理解できる。しかし、グループコーディネーター自身が死亡した場合、そのビューの次のメンバーが(あるロジックによって)コーディネーターとして引き継ぎます。jgroups - グループコーディネータが終了したときの障害検出
- 私の質問は、次のメンバーが新しい ビューについて知る方法です。
- のチャンネルがコーディネーターになり、メンバーと各メンバーに新しいビューをインストールするかどうかは、最初の/最古のメンバー のビューを確認して、 が新しいコーディネーターかどうかを確認しますか?
ありがとう@Bela。古いドキュメントを見て申し訳ありません。しかし、私はまだ疑問がほとんどありません。 "BがSUSPECT(A)メッセージを受信した場合、coord(A)がクラッシュしたときに引き継ぐ必要があることがわかります。つまり、Bはコーディネーターになり、BはVERIFY_SUSPECTを使用し、最終的にAをクラスターから除外し、新しいビュー{B、C、D}をメンバーに公開することを意味します。そうですか?しかし、その場合、VERIFY_SUSPECTを使用した後にAが生きている場合、コーディネーターシップはどうなるのでしょうか? – Sayan
Bは引き継ぎません –
これに関連する質問もあります。 Bもクラッシュするとどうなるでしょうか?メンバーリストがA、B、C、D ...のようになり、現在のコーディネーターと次の候補者の両方が同時にクラッシュした場合、システムはどのように動作しますか?前もってありがとうございます。 –