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

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

非プライマリ読み込み設定（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 で説明されている状況を考慮してください。

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

常に低レイテンシノードから読み取るには、nearest を使用します。ドライバーまたは mongos は、最も近いノードと、最も近いノードから 15 ミリ秒以内の [2] 離れたノードから読み取ります。

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

特定の専用クエリ（例: ETL、レポートなど）の場合は、secondary 読み込み設定（read preference）モードを使用して、プライマリから読み取り負荷をシフトできます。このユースケースでは、secondary モードが secondaryPreferred モードよりも推奨されます。これは、secondaryPreferred では次の状況が発生するリスクがあるためです。すべてのセカンダリが使用できず、レプリカセットにプライマリの停止を防ぐのに十分な アービタ [3] がある場合、プライマリはクライアントからのすべてのトラフィックを受信します。プライマリがこの負荷を処理できない場合、クエリは書き込みと競合します。このため、これらの特定の専用クエリを分散するには、secondaryPreferred ではなく、読み込み設定（read preference）secondary を使用します。