読み込み設定 (read preference) のユースケース

読み込み設定（read preference）モード

• すべてのモードで、ノードはクライアントの定期的な監視チェックに応答するときに使用できます。これは、ノードがネットワーク経由でアクセス可能で、リクエストに応答できることを確認します。

• primaryを除くすべてのモードでは、読み込み設定（read preference）の maxStalenessSeconds オプションと指定されたタグセットリストを満たす場合、ノードは資格があります。

• primaryを除くすべてのモードで、localThresholdMS 接続文字列オプションは、資格のあるメンバーから選択するときにクライアントがレイテンシウィンドウを計算するために使用するローカルしきい値を設定します。

非プライマリ読み込み設定（read preference）を使用するための表示

以下は、primary 以外の読み込み設定（read preference）モードを使用する一般的な使用例です。

• フロントエンド アプリケーションに影響を与えないシステム操作を実行します。

  注意

  読み込み設定（read preference）は、単一の mongod インスタンスへの直接接続には関係ありません。ただし、レプリカセットのセカンダリ ノードへの直接接続で読み取り操作を実行するには、セカンダリ などの読み込み設定（read preference）を設定する必要があります。

• 地理的に分散されたアプリケーションにローカル読み取りを提供します。

  複数のデータセンターにアプリケーション サーバーがある場合は、地理的に分散されたレプリカセットを用意し、非プライマリまたは nearest 読み込み設定（read preference）を使用することを検討してください。これにより、クライアントは常にプライマリから読み取るのではなく、レイテンシーが最も低いノードから読み取ることができます。

• フェイルオーバー中の可用性の維持。

  primaryPreferredアプリケーションが通常の状況ではプライマリから読み取り、プライマリが使用できない場合にセカンダリからの 古い読み取り を許可する場合は、 を使用します。

非プライマリ読み込み設定（read preference）のカウンター表示

一般に、読み取り用の追加容量を提供するために secondary と secondaryPreferred を使用しないでください。その理由は次のとおりです。

• レプリカのすべてのノードの書込みトラフィックはほぼ同等です。その結果、セカンダリはプライマリとほぼ同じ速度で読み取りを処理します。

• レプリケーションは非同期であり、書込み操作の成功とセカンダリへのレプリケーションの間にはある程度の遅延が発生します。セカンダリからの読み取りでは古いデータが返される可能性があり、異なるセカンダリからの読み取りでは非単調な読み取りが発生する可能性があります。

  注意

  クライアントは、クライアント セッションと因果整合性保証を使用して、単調読み取りを保証できます。

• 読み取り操作をセカンダリに分散すると、セットの いずれかのノードが使用できなくなった場合に、セットの残りのノードがすべてのアプリケーションリクエストを処理できる必要があるため、可用性が損なわれる可能性があります。

シャーディングは、読み取りおよび書込み操作をマシンのグループ全体に分散することで読み取りおよび書込み容量を増加させるため、多くの場合、容量を追加するためのより優れた戦略となります。

読み込み設定（read preference）の内部適用の詳細については、「サーバー選択アルゴリズム」を参照してください。

整合性を最大化する

古い読み取りを回避するには、primary読み込み設定（read preference）と "majority" readConcern を使用します。プライマリが使用できない場合（たとえば、選出中やレプリカセットの大部分にアクセスできない場合）、primary 読み込み設定（read preference）を使用した読み取り操作ではエラーが生成されるか、例外がスローされます。

状況によっては、レプリカセットに一時的に 2 つのプライマリが存在する可能性がありますが、"majority" 書込み保証（write concern）で書込みを確認できるプライマリは 1 つだけです。

• 部分的なネットワーク パーティションにより、プライマリ（P _old）が少数のノードを含むパーティションに分離され、パーティションの反対側には大多数のノードが含まれる場合があります。多数派のパーティションは新しいプライマリ（P _new）を選出しますが、レプリカセット内の少数のノードしか認識できないことをまだ検出していないため、しばらくの間、古いプライマリ（P _old）が引き続き読み取りと書込みを処理する可能性があります。この期間中、古いプライマリ（P _old）がプライマリとしてクライアントにまだ表示されている場合は、このプライマリからの読み取りで古いデータが反映される可能性があります。

• プライマリ（P _old）が応答しなくなると選出がトリガーされ、新しいプライマリ（P _new）が選出されて読み取りと書込みを処理できるようになります。応答しないプライマリ（P _old）が再び応答し始めると、2 つのプライマリが短時間表示されます。この短い表示期間は、P _old が終わると終了します。ただし、短期間の間に、クライアントは古いプライマリ P _old から読み取りを行う可能性があり、これにより古いデータが提供される場合があります。

整合性を高めるために、自動 フェイルオーバーを無効にすることができます。ただし、自動フェイルオーバーを無効にすると可用性が低下します。

可用性を最大化する

可能な場合、読み取り操作を許可するには、 primaryPreferredを使用します。プライマリがある場合、コンシステント読み取りが取得されます []1 が、プライマリがない場合はセカンダリをクエリできます。ただし、このsecondary 読み取りモードを使用する場合は、 とsecondaryPreferred で説明されている状況を考慮してください。

レイテンシを最小限に抑える

To always read from a low-latency node, use nearest. The driver or mongos will read from the nearest member and those no more than 15 milliseconds [2] further away than the nearest member.

nearest は整合性を保証するものではありません。アプリケーション サーバーに最も近いノードがレプリケーション ラグのあるセカンダリである場合、クエリによって古いデータが返される可能性があります。nearest はネットワーク距離のみを反映し、I/O または CPU 負荷は反映しません。

地理的に分散したノードからのクエリ

レプリカセットのノードが地理的に分散している場合は、インスタンスの場所を反映するレプリカ タグを作成し、近くのノードを照会するようにアプリケーションを構成できます。

たとえば、「east」および「west」データセンターのノードに タグ {'dc': 'east'} および {'dc': 'west'} が付けられている場合、east データセンターのアプリケーション サーバーは、次の読み込み設定（read preference）を使用して近くのノードから読み取ることができます。

db.collection.find().readPref('nearest', [ { 'dc': 'east' } ])

nearest はすでにネットワーク遅延の少ないノードを優先していますが、タグを含めることで選択がより予測可能になります。

secondary vs secondaryPreferred

For specific dedicated queries (e.g. ETL, reporting), you may shift the read load from the primary by using the secondary read preference mode. For this use case, the secondary mode is preferable to the secondaryPreferred mode because secondaryPreferred risks the following situation: if all secondaries are unavailable and your replica set has enough arbiters [3] to prevent the primary from stepping down, then the primary will receive all traffic from the clients. If the primary is unable to handle this load, the queries will compete with the writes. For this reason, use read preference secondary to distribute these specific dedicated queries instead of secondaryPreferred.