読み取り保証 (read concern) `"linearizable"`

"linearizable"

The query returns data that reflects all successful majority-acknowledged writes that completed prior to the start of the read operation. The query may wait for concurrently executing writes to propagate to a majority of replica set members before returning results.

If a majority of your replica set members crash and restart after the read operation, documents returned by the read operation are durable if writeConcernMajorityJournalDefault is set to the default state of true.

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

You can specify linearizable read concern for read operations on the primary only.

Tip

Always use maxTimeMS with linearizable read concern in case a majority of data bearing members are unavailable. maxTimeMS ensures that the operation does not block indefinitely and instead ensures that the operation returns an error if the read concern cannot be fulfilled.

要件

線形化可能な読み取り保証は、読み取り操作で 1 つのドキュメントを一意に識別するクエリフィルターが指定されている場合にのみ適用されます。さらに、次の条件のいずれも満たされない場合、線形化可能な読み取り保証は一貫性のあるスナップショットから読み取れず、フィルターに一致するドキュメントが返されない可能性があります。

クエリは、クエリの検索キーとして不変のフィールドを使用します。たとえば、_id フィールドで検索したり、$natural を使用したりします。
同時更新によってクエリの検索キーが変更されることはありません。
検索キーにはユニークインデックスがあり、クエリはそのインデックスを使用します。

上記の基準のいずれかが満たされた場合、クエリは一貫性のあるスナップショットから読み取り、一致するドキュメントを 1 つ返します。

Causally Consistent Sessions

読み取り保証（read concern） "linearizable" is unavailable for use with causally consistent sessions.

Aggregation Restriction

You cannot use the $out or the $merge stage in conjunction with read concern "linearizable". That is, if you specify "linearizable" read concern for db.collection.aggregate(), you cannot include either stages in the pipeline.

リアルタイム注文

Combined with "majority" write concern, "linearizable" read concern enables multiple threads to perform reads and writes on a single document as if a single thread performed these operations in real time; that is, the corresponding schedule for these reads and writes is considered linearizable.

自分の書込みを読む

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

パフォーマンスの比較

Unlike "majority", "linearizable" read concern confirms with secondary members that the read operation is reading from a primary that is capable of confirming writes with { w: "majority" } write concern. [1] As such, reads with linearizable read concern may be significantly slower than reads with "majority" or "local" read concerns.

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

以下に例を挙げます。

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を要求したにもかかわらず、古いデータを検出する可能性があり、以前のプライマリへの新しい書き込みは最終的にロールバックされます。

戻る

"過半数"

「スナップショット」

読み取り保証 (read concern) "linearizable"

Tip