"線形化可能 "過半数で発生する可能性のある問題を解決するために、MongoDb3.4で読み取りの懸念が導入されました 「懸念事項を読んでください。
「過半数」の問題を理解してみましょう 「懸念事項を読んで、何を感知するか」線形化可能 「私たちにもたらします。
次のような3つのノードのレプリカセットがあるとします。
ここで、 A プライマリ、 B セカンダリ、 C セカンダリです
2人のユーザーもアリスにしましょう およびボブ 、「 users」にある次のドキュメントに対していくつかの操作を実行します 「コレクション。
{
"_id": 100234,
"name": "Katelyn"
}
時刻T0：
次のことが起こります
- アリスはAに接続します （プライマリ）および次のコマンドを発行します。
出力：
- B およびC A 応答を停止し、選挙手続きを開始します。（ネットワークのパーティション分割が原因である可能性があります 。
時刻T1：
次のことが起こります
- 選挙プロセスにより、Bは新しいプライマリーとしての地位を確立します 。
ただし、その時まで A 伝達されていない、または A それ自体は、プライマリとして機能し続けるセカンダリに降格する必要があることを認識しています（ただし、これは通常、非常に短い期間です）。
時点T2：
- ボブはBに接続されます （新しいプライマリ）および次のコマンドの問題。
- ボブは書き込みを認められています。
時点T3：
- アリスはAに接続します （古いプライマリ）および次のコマンドを発行します。
出力：
ここのアリスは、過半数の読み取りの懸念を発行した後でも古いデータを取得します。つまり、ボブによる書き込みはアリスには表示されません。 したがって、「線形化可能性」のプロパティ "この場合は補償されます。
したがって、ソリューション、つまり「線形化可能」が登場します 「読み取りの懸念。このプロパティを使用すると、mongodはプライマリをチェックし、読み取り操作の結果を発行する前にノードの大部分を確認できます。ただし、この読み取りの懸念を「多数」よりも使用すると、パフォーマンスコストのペナルティが発生するため、これに代わるものではありません。 「大多数」は懸念事項を読みます。
writeConcernMajorityJournalDefaultについて プロパティ、それは単なるレプリカセット構成オプションです。 ブール値を受け入れます 。
正しい つまり、MongoDBは、投票メンバーの過半数がディスク上のジャーナルに書き込みを行った後、書き込み操作を承認します。
誤り つまり、MongoDBは、投票メンバーの過半数がメモリ内で書き込み操作を適用した後、書き込み操作を確認します。
上記のプロパティは、書き込み懸念「マジョリティ」が使用され、ジャーナルフラグが指定されていない場合にのみ適用されます。