プライマリに永続的または一時的に障害が発生した場合、またはネットワーク レベルでレプリカ セットの残りの部分から分離された場合のシナリオでのデータの耐久性に関連して、MongoDB が提供する保証があれば、それを理解したいと思います。
w:1 書き込み懸念で何が起こるかを理解しています。ジャーナリングの役割を理解しています。
新しいプライマリが選択されたときに、MongoDB がどの書き込みを保持し、どの書き込みを破棄するかを決定する方法がわかりません。N1 がプライマリで、N2、N3、N4 がセカンダリの 4 ノード (+ アービター) クラスタで、次のシナリオを実行します。
- {w:majority, j:true} 書き込みがプライマリにヒットします。
- セカンダリは変更をポーリングし、プライマリは過半数が確認されるのを待ちます。
- N2 は変更を確認します。
- N3 は変更を受け取り、適用中です。
- プライマリがダウンします。
- N3 は、変更を適用したことをプライマリに確認できません。
- 選挙は強制。
質問:
- 選挙が完了した後、書き込みは利用可能になりますか?
- どのノードが新しいプライマリになるかは重要ですか?
- ステップ 4 が行われなかった場合、結果は異なりますか?
- プライマリーが N3 から確認を受け取った場合、結果は異なりますか?
- プライマリが書き込みを確認し、N2 が書き込みが過半数で確認されたという事実を複製した場合、結果は異なりますか?
- N2 と N3 の両方が書き込みが多数決で確認されたという事実を複製した場合、結果は異なりますか?