読み取り保証（read concern）

readConcern オプションを使用して、レプリカセットとクラスターから読み取られたデータの整合性と分離を制御します。

書き込み保証と読み取り保証を効果的に使用することで、整合性保証と可用性保証のレベルを調整できます。例、整合性保証が強化されるのを待つか、整合性要件を緩和すると、高可用性が得られます。

レプリカセットとシャーディングされたクラスターは、グローバルなデフォルトの読み取り保証 (read concern)をサポートしています。読み取り保証 (read concern)が明示されていない操作は、グローバルデフォルトのを継承します。詳しくは、setDefaultRWConcern を参照してください。

読み取り保証レベル

次の読み取り保証レベルが利用可能です。

`level`	説明
`"local"`	クエリはインスタンスからデータを返しますが、そのデータがレプリカセットのノードの過半数に書き込まれたことを保証するものではありません。データはロールバックされる場合があります。プライマリとセカンダリに対する読み取りのデフォルト。可用性: 読み取り保証 (read concern) `"local"` は、因果コンシステントなセッションやトランザクションの有無にかかわらず使用できます。詳細については、`"local"` に関する参考ページを参照してください。
`"available"`	クエリはインスタンスからデータを返しますが、そのデータがレプリカセットのノードの過半数に書き込まれたことを保証するものではありません。データはロールバックされる場合があります。可用性: 読み取り保証 `"available"` は、因果整合性を持つセッションおよびトランザクションでは使用できません。シャーディングされたクラスターでは、さまざまな読み取り保証の中で `"available"` 読み取り保証で読み取りのレイテンシーが最低となります。ただし、シャーディングされたコレクションから読み取るときに `"available"` 読み取り保証によって孤立したドキュメントが返される可能性があるため、一貫性が犠牲になります。シャーディングされたコレクションから読み取るときに孤立したドキュメントが返されるリスクを回避するには、読み取り保証 `"local"` などの別の読み取り保証を使用します。詳細については、`"available"` に関する参考ページを参照してください。
`"majority"`	このクエリは、レプリカセットのノードの過半数が承認したデータをします。返されたドキュメントは、障害が発生した場合でも耐久性があります。読み取り保証 (read concern) `"majority"` を満たすために、レプリカセットは、過半数コミット点でメモリ内ビューからデータを返します。読み取り保証 (read concern) `"majority"` のパフォーマンスは他の読み取り保証 (read concern) と同等です。可用性: 読み取り保証 (read concern) `"majority"` は、因果コンシステントなセッションやトランザクションの有無にかかわらず使用できます。要件: レプリカセットでは、WiredTigerストレージエンジンを使用する必要があります。マルチドキュメントトランザクションの場合、読み取り保証 (read concern)`"majority"` は、トランザクションが書込み保証 (write concern)"過半数"でコミットされた場合にのみ保証を提供します。それ以外の場合、`"majority"`はトランザクションで読み取られるデータについて保証しません。詳細については、`"majority"` に関する参考ページを参照してください。
`"linearizable"`	クエリは、読み取り操作の開始前に完了した、過半数が承認した成功した書き込みをすべて反映したデータを返します。クエリは、同時書き込み (write) が過半数のレプリカセットに反映されるのを待ってから、結果を返す場合があります。レプリカセットの過半数がクラッシュして読み取り操作後に再起動した場合、`writeConcernMajorityJournalDefault` がデフォルト値の `true` に設定されていれば、返されるドキュメントは耐久性があります。 `writeConcernMajorityJournalDefault` を `false` に設定すると、MongoDB は書き込みを確認する前に、オンディスクジャーナルに `w: "majority"` 書き込みが書き込まれるのを待たなくなります。そのため、`"majority"` 特定のレプリカセット内の大多数のノードでの一時的な損失（例: クラッシュおよび再起動）が発生したイベントにロールバックされる可能性があります。可用性: 読み取り保証`"linearizable"`は、因果整合性を持つセッションおよびトランザクションでは使用できません。線形化可能な読み取り保証 (read concern)は `primary` の読み取り操作にのみ指定できます。 `$out` または `$merge` ステージを、読み取り保証 `"linearizable"` と組み合わせて使用することはできません。つまり、`"linearizable"` 読み取り保証を `db.collection.aggregate()` に対して指定した場合は、どちらのステージもパイプライン内に含めることができません。要件: 線形化可能な読み取り保証は、読み取り操作で 1 つのドキュメントを一意に識別するクエリフィルターが指定されている場合にのみ適用されます。さらに、次の条件のいずれも満たされない場合、線形化可能な読み取り保証は一貫性のあるスナップショットから読み取れず、フィルターに一致するドキュメントが返されない可能性があります。クエリは、クエリの検索キーとして不変のフィールドを使用します。たとえば、`_id` フィールドで検索したり、`$natural` を使用したりします。同時更新によってクエリの検索キーが変更されることはありません。検索キーにはユニークインデックスがあり、クエリはそのインデックスを使用します。上記の基準のいずれかが満たされた場合、クエリは一貫性のあるスナップショットから読み取り、一致するドキュメントを 1 つ返します。データを含むノードの過半数が利用できない場合は、必ず線形化可能な読み取り保証 (read concern)で `maxTimeMS` を使用してください。`maxTimeMS` を指定すると、読み取り保証 (read concern)が満たされない場合に、操作が無期限にブロックされるのではなく、エラーが返されます。詳細については、`"linearizable"` に関する参考ページを参照してください。
`"snapshot"`	読み取り保証 `"snapshot"` を指定したクエリでは、直近の特定の点のシャード全体に表示れる、過半数のコミット済みデータが返されます。読み取り保証 `"snapshot"` は、トランザクションが書込み保証 `"majority"` でコミットされた場合にのみ保証を提供します。 If a transaction is not part of a causally consistent session, upon transaction commit with write concern `"majority"`, the transaction operations are guaranteed to have read from a snapshot of majority-committed data. If a transaction is part of a causally consistent session, upon transaction commit with write concern `"majority"`, the transaction operations are guaranteed to have read from a snapshot of majority-committed data that provides causal consistency with the operation immediately preceding the transaction start. 可用性: 読み取り保証 (read concern)`"snapshot"` はで利用可能です読み取り保証 (read concern)がトランザクションレベルで設定された、マルチドキュメントトランザクション内のすべての読み取り操作。マルチドキュメントトランザクション以外の以下のメソッド。 `find` `aggregate` `distinct` シャーディングされていないコレクションのみ `"snapshot"` を禁止しているその他すべての操作。

読み取り保証のレベルを問わず、ノード上の最新データにシステム内のデータの最新バージョンが反映されていない場合があります。

各読み取り保証レベルの詳細については、以下を参照してください。

`readConcern` サポート

読み取り保証のオプション

マルチドキュメントトランザクションではない操作では、読み取り保証をサポートするコマンドとメソッドのオプションとして readConcern レベルを指定できます。

readConcern: { level: <level> }

mongosh メソッド db.collection.find() の読み取り保証 (read concern) レベルを指定するには、cursor.readConcern() メソッドを使用します。

db.collection.find().readConcern(<level>)

トランザクションと使用可能な読み取り保証

マルチドキュメントトランザクションの場合は、個々の操作レベルではなく、トランザクションレベルで読み取り保証 (read concern)を設定します。トランザクション操作では、トランザクションレベルの読み取り保証 (read concern)が使用されます。コレクションおよびデータベースレベルで設定された読み取り保証は、トランザクション内では無視されます。トランザクションレベルの読み取り保証 (read concern)を明示的に設定すると、クライアントレベルの読み取り保証 (read concern)も無視されます。

重要

個々の操作に対して読み取り保証 (read concern)を明示的に設定しないでください。トランザクションの読み取り保証 (read concern)を設定するには、読み取り保証 (read concern)/書込み保証 (write concern)/読み込み設定 (read preference) を参照してください。

読み取り保証は、トランザクションの開始時に設定できます。

マルチドキュメントトランザクションは次の読み取り保証 (read concern)レベルをサポートします。
マルチドキュメントトランザクションの一部である書き込みコマンドは、トランザクションレベルの読み取り保証をサポートできます。
トランザクション内でコレクションとインデックスを作成できます。コレクションまたはインデックスを明示的に作成する場合、トランザクションは読み取り保証 "local" を使用する必要があります。コレクションを暗黙的に作成する場合は、トランザクションに使用できる任意の読み取り保証を使用できます。

トランザクションの開始時に指定されていない場合、トランザクションはセッションレベルの読み取り保証を使用するか、設定されていない場合はクライアントレベルの読み取り保証を使用します。

詳細については、「トランザクション読み取り保証」を参照してください。

因果整合性セッションと使用可能な読み取り保証

因果コンシステントセッションの操作では、"local"、"majority"、および"snapshot" レベルが使用できます。因果整合性を保証するには、"majority" を使用します。詳細については、因果整合性を参照してください。

読み取り保証をサポートする操作

以下の操作が、読み取り保証をサポートします。

重要

トランザクションの操作に読み取り保証を設定するには、個々の操作レベルではなくトランザクションレベルで読み取り保証を設定します。トランザクションにおける個々の操作に対して読み取り保証を明示的に設定しないでください。詳細については、「トランザクションと読み取り保証」を参照してください。

コマンド/メソッド	`"local"`	`"available"`	`"majority"`	`"snapshot"` [3]	`"linearizable"`
`count`	✓	✓	✓		✓
`distinct`	✓	✓	✓	✓ [2]	✓
`find`	✓	✓	✓	✓	✓
`db.collection.find()` via `cursor.readConcern()`	✓	✓	✓	✓	✓
`getMore`	✓				✓
`aggregate` `db.collection.aggregate()`	✓	✓	✓	✓	✓ [3]
`Session.startTransaction()`	✓		✓	✓

[1]	`$out` または `$merge` ステージを、読み取り保証 `"linearizable"` と組み合わせて使用することはできません。つまり、`"linearizable"` 読み取り保証を `db.collection.aggregate()` に対して指定した場合は、どちらのステージもパイプライン内に含めることができません。

[2]	読み取り保証 `"snapshot"` は、特定の読み取り操作およびマルチドキュメントトランザクションに対してのみ使用できます。トランザクションでは、シャーディングされたコレクションで `distinct` コマンドやそのヘルパーを使用することはできません。

マルチドキュメントトランザクションの一部である場合は、次の書き込み操作でも読み取り保証を受け付けることができます。

重要

トランザクションの操作に読み取り保証を設定するには、個々の操作レベルではなくトランザクションレベルで読み取り保証を設定します。

コマンド	`"local"`	`"snapshot"` [3]
`delete` `db.collection.deleteOne()` `db.collection.deleteMany()` `db.collection.remove()`	✓	✓
`findAndModify` `db.collection.findAndModify()` `db.collection.findOneAndDelete()` `db.collection.findOneAndReplace()` `db.collection.findOneAndUpdate()`	✓	✓
`insert` `db.collection.insertOne()` `db.collection.insertMany()`	✓	✓
`update` `db.collection.updateOne()` `db.collection.updateMany()` `db.collection.replaceOne()`	✓	✓
`create` `db.createCollection()` (Requires FCV 6.0 or greater)	✓
`createIndexes` `db.collection.createIndex()` `db.collection.createIndexes()` (Requires FCV 6.0 or greater)	✓

[3]	(1、2) 読み取り保証 (read concern) `"snapshot"` は、特定の読み取り操作およびマルチドキュメントトランザクションでのみ使用できます。トランザクションの場合は、トランザクションレベルで読み取り保証 (read concern)を設定します。`"snapshot"` をサポートするトランザクション操作は、トランザクションで使用可能なCRUD操作に対応します。詳細については、「トランザクションと読み取り保証 (read concern) 」を参照してください。

`local` データベースでは読み取り保証 (read concern) はサポートされていません

ローカルデータベースは読み取り保証 (read concern) をサポートしていません。MongoDB は、ローカルデータベース内のコレクションに対する操作に対して構成された読み取り保証 (read concern)を暗黙的に無視します。

Considerations

自分の書込みを読む

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

リアルタイム注文

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

パフォーマンスの比較

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

データを含むノードの過半数が利用できない場合は、必ず線形化可能な読み取り保証 (read concern)で maxTimeMS を使用してください。maxTimeMS を指定すると、読み取り保証 (read concern)が満たされない場合に、操作が無期限にブロックされるのではなく、エラーが返されます。

以下に例を挙げます。

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

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

読み取り操作および `afterClusterTime`

MongoDB は因果コンシステントなセッションをサポートしています。因果整合性のあるセッションでの読み取り操作の場合、ドライバーは afterClusterTime読み取り保証 (read concern)オプションを自動的に設定します。

重要

読み取り操作のために afterClusterTime を手動で設定しないでください。MongoDBドライバーは、因果整合性のあるセッションの操作に対して、この値を自動的に設定します。ただし、別のクライアントセッションの操作とコンシステントにするなど、セッションのoperation timeやクラスター時間を繰り上げることはできます。例については、例を参照してください。

注意

afterClusterTime とともに atClusterTime を指定することはできません。読み取り保証 "snapshot" で atClusterTime を使用するには、因果整合性のあるセッションを無効にします。

afterClusterTime 値が T の読み取りリクエストを満たすには、mongod はoplogが時間 T に達した後にリクエストを実行する必要があります。oplogが時間 T に達していない場合、mongod はリクエストを処理するのを待機します。

指定された afterClusterTime を使用した読み取り操作では、読み取り保証 (read concern)レベル要件と指定された afterClusterTime 要件の両方を満たすデータが返されます。

因果整合性のあるセッションに関連付けられていない読み取り操作の場合、afterClusterTime は設定されません。