3 つのメンバーが 3 つの独立したネットワーク ノードに展開されている典型的なレプリカ セット (1 つのプライマリ、1 つのセカンダリ、および 1 つのアービター) のシナリオを考えてみます。プライマリとセカンダリの間のネットワーク接続が切断された場合、他は問題ありませんが、mongodb はどのように反応しますか?
この状況では、アービターはプライマリとセカンダリが両方とも動作していることを認識しており、プライマリは実際には影響を受けませんが、セカンダリの切断を報告し続けますが、セカンダリに対して、プライマリになるための選択をトリガーしますか? では、元のプライマリーはどうなるでしょうか。等々。
何が起こるかわからないし、このシナリオを自分の PC で作成するのは難しいです。誰も手がかりを持っていますか？
3 つのノードのレプリカ セットがある場合、2 つのメンバーが相互に認識できる (そしてそのうちの 1 つがデータ ベアリング ノードである) 限り、プライマリを選択できます。
したがって、1 つのノードが完全に切断されている可能性のあるシナリオ:
プライマリとアービターが他のものを認識できる場合(ただし、セカンダリは認識できない)、選出は行われませんが、ネットワーク接続が復元されるまで、セカンダリはレプリケーション ラグの蓄積を開始します (または、セカンダリの oplogにプライマリとの共通点がなくなり、再同期されます）。
プライマリとセカンダリが相互に認識できる場合(ただし、アービターは認識できない)、選択は行われず、レプリケーションは通常どおり続行されます。
セカンダリとアービターが他のものを認識できる場合(ただし、プライマリは認識できない)、セカンダリがプライマリとして選択されます。レプリケーション ラグがあった場合、以前のプライマリに書き込まれたエントリがセカンダリで受け入れられなかった可能性があります。以前のプライマリが (セカンダリとして) レプリカ セットに再び参加できるようになると、現在のプライマリにレプリケートされなかったすべての操作がロールバックとして保存されます。
プライマリとセカンダリがアービターを見ることができるが、お互いを見ることができない部分的な切断の場合、アービターはセカンダリよりも新しいアクティブなプライマリを見ることができるため、セカンダリは選択を開始しようとしますが、拒否されると予想されます。 (いずれかのノードが拒否した場合、選択は失敗します)。
ネットワークの可用性に一貫性がない場合は、よりトリッキーなケースがあります。この場合、プライマリが断続的に到達不能になると、レプリカ セットで「フラッピング」(連続する選択) が発生する可能性があります。
ネットワーク シナリオをシミュレートする 1 つの方法は、ファイアウォール ルール (ブロック用) と(遅延またはパケット損失を導入するためのtcトラフィック制御) などのツールを使用することです。またmongobridge、MongoDB ソース ツリーでコンパイルできるツールもあります (参照: mongobridge を使用したネットワーク パーティションのシミュレート) .
その他の有用な読み物:
この質問は、次のバグによって回答されていると思います: https://jira.mongodb.org/browse/SERVER-9730 「どのような状況でも、プライマリが既に存在する間は投票しないでください」したがって、2 つのプライマリはありません。