MongoDBレプリケーションで「アービター」が必要なのはなぜですか？
アービターなしでMongoDBレプリケーションをセットアップすると仮定します プライマリが使用できない場合、レプリカセットはセカンダリをプライマリに選択します。 だから、暗黙的アービター。レプリカがプライマリーを自動的に選出するため。
では、なぜ専用のアービターノードが必要なのでしょうか。ありがとう！
私は スプレッドシートを作成しました レプリカセット内のアービターノードの効果をよりよく説明するため。
それは基本的にこれらのポイントに帰着します：
- RSが2データノードの場合、1台のサーバーを失うと、投票の最小値（「N/2より大きい」）を下回ります。アービターがこれを解決します。
- RSが偶数のデータノードの場合、アービターを追加すると、分割により2つの投票クラスターを持つことを可能にすることなく、フォールトトレランスが1増加します。
- RSが奇数番号のデータノードの場合、アービターを追加すると、スプリットで「N/2より大きい」投票を持つ2つの分離されたクラスターを作成できるため、スプリットブレインシナリオになります。
選挙は詳細に説明されています ここ 。その文書では、RSは50のメンバー（偶数）と7つの投票メンバーを持つことができると状態と述べています。それがどのように機能するか説明しないので、私は「状態」を強調します。私には、片方が4メンバー（すべて投票）でもう片方が46メンバー（3投票）の分割が発生した場合、46がプライマリーを選出し、4がリードになるようにしたいようです。クラスタのみ。しかし、それこそが「制限付き投票」が防ぐものです。その状況では、実際には、読み取り専用のプライマリと46メンバーのクラスターを持つ4メンバーのクラスターがあります。それが理にかなっていることを説明することは、この質問の範囲外であり、私の知識を超えています。
これは本当にCAPの定理に帰着し、パーティションのどちらかの側に同じ数のサーバーがある場合、データベースはCAP（整合性、可用性、およびパーティションの許容範囲）を維持できないと述べられています。アービターは、一方の側に「不均衡」または過半数を作成するように特別に設計されているため、この場合はプライマリを選択できます。
どちらかの側で偶数のノードを取得した場合、MongoDBはプライマリを選択せず、セットは書き込みを受け入れません。
編集する
どちらの側でも、たとえば、片側に2つ、もう一方に2つという意味です。私の英語はそこで簡単に理解できませんでした。
つまり、私が実際に意味するのは両面です。
編集する
ウィキペディアはCAPを説明するためのかなり良い例を提示します： http://en.wikipedia.org/wiki/CAP_theorem
以下の理由により、レプリケーションにアービターが必要です。
- 複製セットの数が奇数である場合、複製はより信頼性が高くなります。偶数のレプリカセットがある場合は、レプリケーションにアービターを追加することをお勧めします。
- アービター保持しないデータが含まれていて、ノードに障害が発生した場合に選挙で投票します。
- アービターは、ハードウェアリソースをあまり消費しない軽量プロセスです。
- アービターは、暗号化されたレプリカセット間でユーザー資格情報データを交換するだけです。
- 選挙中の投票、ハートビート、構成データは、レプリカセット間で通信している間は暗号化されません。
- 高可用性を維持するには、レプリカセットのいずれかと一緒にではなく、別のマシンでアービターを実行することをお勧めします。
お役に立てれば ！！！
アービターはオプションのメカニズムであり、レプリカセットにデプロイされた偶数のmongodsがある場合に投票を成功させることができます。アービターは軽量であり、専用のmongoレプリカではないサーバーにデプロイすることを意図しています。つまり、サーバーの主な役割は、redisサーバーのような他のタスクです。それらは軽いので、システムのリソースに（著しく）干渉しません。
ドキュメントから：
アービターはデータセットのコピーを持たず、プライマリになることはできません。レプリカセットには、予備選挙の選挙で投票を追加する調停者がいる場合があります。アービターにより、データをレプリケートするメンバーのオーバーヘッドなしで、レプリカセットに不均一な数のメンバーを含めることができます。