2.9 に更新:
autoConnectRetryは単に、予期しない切断後にドライバーがサーバーへの再接続を自動的に試行することを意味します。本番環境では、通常、これを true に設定します。
connectionsPerHostは、単一の Mongo インスタンス (シングルトンであるため、通常はアプリケーションごとに 1 つ) が mongod/mongos プロセスに対して確立できる物理接続の量です。執筆時点では、実際のクエリ スループットが低くても、Java ドライバーは最終的にこの量の接続を確立します (つまり、アプリ サーバーごとにこの数に達するまで、mongostat の「conn」統計が上昇することがわかります)。
ほとんどの場合、これを 100 より大きく設定する必要はありませんが、この設定は「テストして確認する」ものの 1 つです。サーバーへの合計接続数が上限を超えないように、これを十分に低く設定する必要があることに注意してください。
db.serverStatus().connections.available
本番環境では、これは現在 40 です。
connectTimeout。名前が示すように、接続試行が中止されるまでドライバーが待機するミリ秒数です。正常な接続試行の妨げになる可能性が現実的で予想される場合を除き、タイムアウトを長め (15 ～ 30 秒) に設定します。通常、接続試行に数秒以上かかる場合は、ネットワーク インフラストラクチャが高スループットに対応していません。
maxWaitTime . 接続が接続プールで使用可能になるまでスレッドが待機するミリ秒数。これが時間内に発生しない場合は例外が発生します。デフォルトのままにします。
ソケットタイムアウト。標準のソケット タイムアウト値。60 秒 (60000) に設定します。
threadsAllowedToBlockForConnectionMultiplier。プールが現在使い果たされている場合に、接続が使用可能になるまで待機できるスレッドの数を示す connectionsPerHost の乗数。これは、「com.mongodb.DBPortPool$SemaphoresOut: Out of semaphores to get db connection」例外の原因となる設定です。このスレッド キューが threadsAllowedToBlockForConnectionMultiplier 値を超えると、この例外がスローされます。たとえば、connectionsPerHost が 10 で、この値が 5 の場合、前述の例外がスローされる前に最大 50 のスレッドがブロックされる可能性があります。
スループットに大きなピークが予想され、大きなキューが一時的に発生する可能性がある場合は、この値を増やしてください。まさにその理由で、現時点で 1500 になっています。クエリの負荷が一貫してサーバーを上回っている場合は、それに応じてハードウェア/スケーリングの状況を改善する必要があります。
readPreference。(更新、2.8+)デフォルトの読み取り設定を決定するために使用され、「slaveOk」を置き換えます。クラス ファクトリ メソッドの 1 つを使用して ReadPreference を設定します。最も一般的な設定の完全な説明は、この記事の最後にあります
w。(更新、2.6+)この値は、書き込みの「安全性」を決定します。この値が -1 の場合、ネットワークまたはデータベースのエラーに関係なく、書き込みはエラーを報告しません。WriteConcern.NONE は、これに適した定義済みの WriteConcern です。w が 0 の場合、ネットワーク エラーにより書き込みが失敗しますが、mongo エラーは発生しません。これは通常、「ファイア アンド フォーゲット」書き込みと呼ばれ、一貫性や耐久性よりもパフォーマンスが重要な場合に使用する必要があります。このモードには WriteConcern.NORMAL を使用します。
w を 1 以上に設定すると、書き込みは安全であると見なされます。安全な書き込みは書き込みを実行し、サーバーへの要求によってフォローアップして、書き込みが成功したことを確認するか、失敗した場合はエラー値を取得します (つまり、書き込み後に getLastError() コマンドを送信します)。この getLastError() コマンドが完了するまで、接続は予約されていることに注意してください。それと追加のコマンドの結果として、スループットは w <= 0 の書き込みよりも大幅に低くなります。 aw 値がちょうど 1 の場合、MongoDB は、書き込みを送信したインスタンスで書き込みが成功した (または検証可能に失敗した) ことを保証します。
レプリカ セットの場合、MongoDB に、レプリカ セットの少なくとも "w" メンバーに書き込みを送信してから (より正確には、"w" メンバーへの書き込みのレプリケーションを待機するように指示する) w に高い値を使用できます。 ）。また、w を文字列 "majority" に設定することもできます。これにより、MongoDB に大部分のレプリカ セット メンバー (WriteConcern.MAJORITY) への書き込みを実行するように指示されます。生のパフォーマンス (-1 または 0) またはレプリケートされた書き込み (>1) が必要でない限り、通常はこれを 1 に設定する必要があります。1 より大きい値は、書き込みスループットに大きな影響を与えます。
fsync。有効にすると、書き込みごとに mongo が強制的にディスクにフラッシュする持続性オプション。書き込みバックログに関連する耐久性の問題はこれまで一度もなかったので、本番環境ではこれを false (デフォルト) にしています。
j * (NEW 2.7+) *. true に設定すると、MongoDB がジャーナリング グループのコミットが成功するまで待機してから戻るように強制するブール値。ジャーナリングを有効にしている場合は、これを有効にして耐久性を高めることができます。http://www.mongodb.org/display/DOCS/Journalingを参照して、どのようなジャーナリングが得られるか (および、このフラグを有効にする理由) を確認してください。
ReadPreference
ReadPreference クラスを使用すると、レプリカ セットを使用している場合に、どの mongod インスタンスにクエリをルーティングするかを構成できます。次のオプションが利用可能です。
ReadPreference.primary() : すべての読み取りは、repset プライマリ メンバーのみに行われます。すべてのクエリが一貫した (最後に書き込まれた) データを返す必要がある場合は、これを使用します。これがデフォルトです。
ReadPreference.primaryPreferred() : すべての読み取りは、可能な場合は repset プライマリ メンバーに行われますが、プライマリ ノードが使用できない場合はセカンダリ メンバーを照会する場合があります。そのため、プライマリが使用できなくなった場合、読み取りは結果整合性になりますが、プライマリが使用できない場合に限られます。
ReadPreference.secondary() : すべての読み取りはセカンダリ repset メンバーに送られ、プライマリ メンバーは書き込みのみに使用されます。これは、結果整合性のある読み取りを使用できる場合にのみ使用してください。追加の repset メンバーを使用して読み取りパフォーマンスをスケールアップできますが、repset が持つことができる (投票) メンバーの量には制限があります。
ReadPreference.secondaryPreferred() : すべての読み取りは、いずれかが使用可能な場合、セカンダリ repset メンバーに移動します。すべてのセカンダリ メンバーが使用できなくなるまで、プライマリ メンバーは書き込み専用に使用されます。読み取り用のプライマリ メンバーへのフォールバック以外は、ReadPreference.secondary() と同じです。
ReadPreference.nearest() : 読み取りは、データベース クライアントが使用できる最も近い repset メンバーに移動します。結果整合性のある読み取りが許容される場合にのみ使用してください。最も近いメンバーは、クライアントとさまざまな repset メンバーの間の待ち時間が最も短いメンバーです。忙しいメンバーは最終的に待ち時間が長くなるため、これにより読み取り負荷のバランスが自動的に調整されるはずですが、私の経験では、メンバーの待ち時間が比較的一貫している場合、セカンダリ (優先) の方がうまくいくようです。
注 : 上記のすべてには、代わりに TaggableReadPreference インスタンスを返す同じメソッドのタグ対応バージョンがあります。レプリカ セット タグの完全な説明は、ここにあります:レプリカ セット タグ