読み取り保証(read concern)
readConcern
オプションを使用すると、レプリカセットおよびシャーディングされたクラスターから読み取られたデータの一貫性と分離プロパティを制御できます。
書き込み保証と読み取り保証を効果的に使用することで、整合性保証のレベルと可用性保証のレベルを必要に応じて調整できます。たとえば、待ち時間を長くして整合性保証を強化したり、整合性要件を緩和して可用性を高めたりできます。
レプリカセットとシャーディングされたクラスターは、グローバルなデフォルトの読み取り保証 (read concern) の設定をサポートしています。読み取り保証 (read concern) を明示的に指定しない操作は、グローバルデフォルトの読み取り保証 (read concern) 設定を継承します。詳細については、setDefaultRWConcern
を参照してください。
読み取り保証レベル
次の読み取り保証レベルが利用可能です。
level | 説明 |
---|---|
クエリはインスタンスからデータを返しますが、そのデータがレプリカセットのノードの大半に書き込まれた(つまり、ロールバックされる可能性がある)という保証はありません。 可用性: 読み取り保証 シャーディングされたクラスターでは、さまざまな読み取り保証の中で 詳細については、 | |
このクエリは、レプリカセットのノードの過半数が承認したデータをします。読み取り操作によって返されたドキュメントは、失敗した場合でも耐久性があります。 読み取り保証「majority」を満たすために、レプリカセットのノードは、過半数がコミットしたポイントでデータのメモリ内ビューからデータを返します。そのため、読み取り保証 可用性: 読み取り保証 要件: マルチドキュメントトランザクションの操作の場合、読み取り保証 詳細については、 | |
クエリは、読み取り操作の開始前に完了した、過半数が承認した成功した書き込みをすべて反映したデータを返します。クエリは、同時に実行されている書き込みが大多数のレプリカセット ノードに反映されるのを待ってから、結果を返す場合があります。 レプリカセット ノードの大部分がクラッシュして読み取り操作後に再起動した場合、
要件: 線形化可能な読み取り保証は、読み取り操作で 1 つのドキュメントを一意に識別するクエリフィルターが指定されている場合にのみ適用されます。さらに、次の条件のいずれも満たされない場合、線形化可能な読み取り保証は一貫性のあるスナップショットから読み取れず、フィルターに一致するドキュメントが返されない可能性があります。
上記の基準のいずれかが満たされた場合、クエリは一貫性のあるスナップショットから読み取り、一致するドキュメントを 1 つ返します。 データを含むノードの大半が利用できない場合に備えて、必ず線形化可能な読み取り条件で 詳細については、 | |
読み取り保証 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.可用性: 読み取り保証
|
読み取り保証のレベルを問わず、ノード上の最新データにシステム内のデータの最新バージョンが反映されていない場合があります。
各読み取り保証レベルの詳細については、以下を参照してください。
readConcern
サポート
読み取り保証のオプション
マルチドキュメントトランザクションではない操作では、読み取り保証をサポートするコマンドとメソッドのオプションとして readConcern
レベルを指定できます。
readConcern: { level: <level> }
mongosh
メソッド db.collection.find()
の読み取り保証 (read concern) レベルを指定するには、cursor.readConcern()
メソッドを使用します。
db.collection.find().readConcern(<level>)
トランザクションと使用可能な読み取り保証
マルチドキュメントトランザクションの場合、読み取り保証は、トランザクション レベルで設定します。個々の操作レベルではありません。トランザクションの操作には、トランザクションレベルの読み取り保証が使用されます。コレクションおよびデータベースレベルで設定された読み取り保証は、トランザクション内では無視されます。トランザクション レベルの読み取り保証が明示的に指定されている場合、トランザクション内ではクライアント レベルの読み取り保証も無視されます。
重要
個々の操作に対して読み取り保証を明示的に設定しないでください。トランザクションの読み取り保証を設定するには、「読み取り保証/書き込み保証/読み込み設定」を参照してください。
読み取り保証は、トランザクションの開始時に設定できます。
マルチドキュメントトランザクションの場合、次の読み取り保証レベルが使用できます。
マルチドキュメントトランザクションの一部である書き込みコマンドは、トランザクションレベルの読み取り保証をサポートできます。
トランザクション内でコレクションとインデックスを作成できます。コレクションまたはインデックスを明示的に作成する場合、トランザクションは読み取り保証
"local"
を使用する必要があります。コレクションを暗黙的に作成する場合は、トランザクションに使用できる任意の読み取り保証を使用できます。
トランザクションの開始時に指定されていない場合、トランザクションはセッションレベルの読み取り保証を使用するか、設定されていない場合はクライアントレベルの読み取り保証を使用します。
詳細については、「トランザクション読み取り保証」を参照してください。
因果整合性セッションと使用可能な読み取り保証
因果整合性セッションの操作では、 "local"
レベル、"majority"
レベル、および"snapshot"
レベルが使用できます。ただし、因果整合性を保証するには、"majority"
を使用する必要があります。詳細については、「因果整合性」を参照してください。
読み取り保証をサポートする操作
以下の操作が、読み取り保証をサポートします。
重要
トランザクションの操作に読み取り保証を設定するには、個々の操作レベルではなくトランザクションレベルで読み取り保証を設定します。トランザクションにおける個々の操作に対して読み取り保証を明示的に設定しないでください。詳細については、「トランザクションと読み取り保証」を参照してください。
[1] | $out または $merge ステージを、読み取り保証 "linearizable" と組み合わせて使用することはできません。つまり、"linearizable" 読み取り保証を db.collection.aggregate() に対して指定した場合は、どちらのステージもパイプライン内に含めることができません。 |
[2] | 読み取り保証 "snapshot" は、特定の読み取り操作およびマルチドキュメントトランザクションに対してのみ使用できます。トランザクションでは、シャーディングされたコレクションで distinct コマンドやそのヘルパーを使用することはできません。 |
マルチドキュメントトランザクションの一部である場合は、次の書き込み操作でも読み取り保証を受け付けることができます。
重要
トランザクションの操作に読み取り保証を設定するには、個々の操作レベルではなくトランザクションレベルで読み取り保証を設定します。
コマンド | |||||
---|---|---|---|---|---|
✓ | ✓ | ||||
✓ | ✓ | ||||
✓ | ✓ | ||||
✓ | ✓ | ||||
✓ | |||||
✓ |
[3] | ( 1、2 )読み取り保証 "snapshot" は、特定の読み取り操作およびマルチドキュメントトランザクションでのみ使用できます。トランザクションの場合は、トランザクション レベルで読み取り保証を設定します。"snapshot" をサポートするトランザクション操作は、トランザクションで使用可能な CRUD 操作に対応します。詳細については、「トランザクションと読み取り保証」を参照してください。 |
local
データベースで読み取り保証はサポートされていません
ローカル データベースは読み取り保証をサポートしていません。MongoDB は、ローカルデータベース内のコレクションに対する操作に対して構成された読み取り保証を暗黙的に無視します。
Considerations
自分の書込みを読む
書き込みリクエスト確認をする場合は、非公式のコンシステントセッションを使用して自分の書き込みを読み取ることができます。
リアルタイム注文
"majority"
書込み保証と組み合わせると、"linearizable"
読み取り保証により、複数のスレッドが単一のドキュメントに対して読み取りと書き込みを、単一のスレッドがこれらの操作をあたかもリアルタイムであるかのように実行できるようになります。つまり、これらの読み取りと書き込みの対応するスケジュールは線形化可能であると見なされます。
パフォーマンスの比較
"majority"
とは異なり、"linearizable"
読み取り保証は、読み取り操作が { w: "majority" }
書込み保証で書き込みを確認できるプライマリから読み取られていることをセカンダリ ノードに確認します。[4] そのため、線形化可能な読み取り保証による読み取りは、"majority"
読み取り保証や "local"
読み取り保証による読み取りよりも大幅に遅くなる可能性があります。
データを含むノードの大半が利用できない場合に備えて、必ず線形化可能な読み取り条件で maxTimeMS
を使用してください。maxTimeMS
を指定すると、操作が無期限に停止することはなく、代わりに読み取りの問題が満たされない場合に操作がエラーを返すようになります。
以下に例を挙げます。
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 には非公式のコンシステントセッションのサポートが含まれています。非公式のコンシステントセッションに関連付けられた読み取り操作の場合、MongoDB は、非公式のコンシステントセッションに関連付けられた操作のドライバーによって自動的に設定される afterClusterTime
読み取り保証 (read concern) オプションをサポートしています。
重要
読み取り操作のために手動で afterClusterTime
を設定しないでください。MongoDB ドライバーは、因果整合性のあるセッションに関連付けられた操作に対して、この値を自動的に設定します。ただし、別のクライアントセッションの操作と一致させるなど、セッションの optime やクラスター時間を繰り上げることはできます。例については、「例」を参照してください。
注意
afterClusterTime
と組み合わせてatClusterTimeを指定することはできません。 読み取り保証 "snapshot"
で atClusterTime を使用するには、因果整合性のあるセッションを無効にする必要があります。
T
の afterClusterTime
値がある読み取りリクエストを満たすには、mongod
は oplog が時間 T
に達した後にリクエストを実行する必要があります。oplog が時間 T
に達していない場合、mongod
はリクエストを処理するまで待機する必要があります。
指定された afterClusterTime
を使用した読み取り操作では、読み取り保証 (read concern) レベル要件と指定された afterClusterTime
要件の両方を満たすデータが返されます。
因果整合性のあるセッションに関連付けられていない読み取り操作の場合、afterClusterTime
は設定されません。
読み取り保証 (read concern) の出所
MongoDB は、特定の読み取り保証 (read concern) のソースを示している provenance
読み取り保証 (read concern) を追跡します。getLastError
メトリクス、読み取り保証 (read concern) エラーオブジェクト、MongoDB ログに provenance
が表示されることがあります。
次の表は、読み取り保証 (read concern) の provenance
に指定可能な値とその意味を示しています。
出所 | 説明 |
---|---|
clientSupplied | 読み取り保証 (read concern) がアプリケーションで指定されました。 |
customDefault | 読み取り保証 (read concern) は、カスタム定義されたデフォルト値に基づきます。 setDefaultRWConcern を参照してください。 |
implicitDefault | 他の読み取り保証 (read concern) が一切指定されていない状態で、読み取り保証 (read concern) がサーバーから発生しました。 |