読み取り保証（read concern） `"linearizable"`

"linearizable"

クエリは、読み取り操作の開始前に完了した、過半数が承認した成功した書き込みをすべて反映したデータを返します。クエリは、同時に実行されている書き込みが大多数のレプリカセットノードに反映されるのを待ってから、結果を返す場合があります。

レプリカセットノードの大部分がクラッシュして読み取り操作後に再起動した場合、 writeConcernMajorityJournalDefaultがデフォルト状態のtrueに設定されていれば、読み取り操作によって返されるドキュメントは耐久計があります。

writeConcernMajorityJournalDefault を false に設定すると、MongoDB は書き込みを確認する前に、オンディスクジャーナルに w: "majority" 書き込みが書き込まれるのを待たなくなります。そのため、"majority" 特定のレプリカセット内の大多数のノードでの一時的な損失（例: クラッシュおよび再起動）が発生したイベントにロールバックされる可能性があります。

線形化可能な読み取り保証は primary の読み取り操作にのみ指定できます。

線形化可能な読み取り保証による保証は、読み取り操作で 1 つのドキュメントを一意に識別するクエリフィルターが指定されている場合にのみ適用されます。

Tip

データを含むノードの大半が利用できない場合に備えて、必ず線形化可能な読み取り条件で maxTimeMS を使用してください。maxTimeMS を指定すると、操作が無期限に停止することはなく、代わりに読み取りの問題が満たされない場合に操作がエラーを返すようになります。

因果整合性セッション

読み取り保証 "linearizable"は、因果整合性のあるセッションでは使用できません。

集計制限

$outまたは$mergeステージは、読み取り保証（read concern "linearizable"と組み合わせて使用できません。 "linearizable"db.collection.aggregate()そのため、に対しての読み取り保証を指定した場合、いずれのステージもパイプラインに含めることはできません。

リアルタイム注文

"majority"書込み保証と組み合わせると、 "linearizable"読み取り保証により、複数のスレッドが単一のドキュメントに対して読み取りと書込みを、単一のスレッドがこれらの操作をあたかもリアルタイムであるかのように実行できるようになります。つまり、これらの読み取りと書き込みの対応するスケジュールは線形化可能であると見なされます。

自分の書込みを読む

書き込みリクエスト確認をする場合は、非公式のコンシステントセッションを使用して自分の書き込みを読み取ることができます。

パフォーマンスの比較

"majority"とは異なり、 "linearizable"読み取り保証は、読み取り操作が{ w: "majority" }書込み保証で書込みを確認できるプライマリから読み取られていることをセカンダリノードに確認します。 [ 1 ]そのため、線形化可能な読み取り保証による読み取りは、 "majority"または"local"読み取り保証による読み取りよりも大幅に遅くなる可能性があります。

以下に例を挙げます。

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)
db.runCommand( {
     find: "restaurants",
     filter: { _id: 5 },
     readConcern: { level: "linearizable" },
     maxTimeMS: 10000
} )

[1] 状況によっては、 replica set内の 2 つのノードが一時的に自分たちがプライマリであると認識することがありますが、最大でそのうちの 1 つが{ w: "majority" }書き込み懸念で書き込みを完了できます。 { w: "majority" }書き込みを完了できるノードは現在のプライマリであり、もう一方のノードは、通常はネットワークパーティションが原因で降格をまだ認識していない以前のプライマリです。これが発生すると、以前のプライマリに接続するクライアントは、読み取り設定primaryを要求したにもかかわらず、古いデータを検出する可能性があり、以前のプライマリへの新しい書き込みは最終的にロールバックされます。

戻る

"過半数"

「スナップショット」