[解決済み] MongoDBのJavaドライバMongoOptionsを本番用に設定する方法とは？

質問

MongoDB Java ドライバーの MongoOptions を設定するためのベストプラクティスをウェブで探しているのですが、API 以外にはあまり出てきません。この検索は、私が "com.mongodb.DBPortPool$SemaphoresOut に遭遇した後に始まりました。out of semaphores to get db connection"エラーに遭遇し、接続数/multiplierを増やすことでその問題を解決することができました。私は、実稼働のためにこれらのオプションを構成する際のリンクまたはあなたのベストプラクティスを探しています。

2.4 ドライバーのオプションは次のとおりです。 http://api.mongodb.org/java/2.4/com/mongodb/MongoOptions.html

• autoConnectRetry
• コネクションパーホスト
• 接続タイムアウト
• maxWaitTime
• ソケットタイムアウト
• threadsAllowedToBlockForConnectionMultiplier（コネクションマルチプライヤー）。

新しいドライバにはより多くのオプションがあり、それらについても聞いてみたいと思っています。

どのように解決するのですか?

2.9にアップデートしました。

• autoConnectRetry は、予期せぬ切断の後、ドライバが自動的にサーバへの再接続を試みることを意味します。実稼働環境では、通常これを true に設定します。

• connectionsPerHost は、ひとつの Mongo インスタンス (シングルトンなので、通常はアプリケーションごとにひとつ) が mongod/mongos プロセスに確立できる物理接続の量です。実際のクエリのスループットが低くても、Java ドライバはこの量の接続を確立します (つまり、mongostat の "conn" 統計がアプリケーションサーバーごとにこの数に達するまで上昇します)。

  ほとんどの場合、この値を 100 よりも大きく設定する必要はありませんが、この設定は「テストしてみてから判断する」ことの 1 つです。サーバーへの接続の合計量が 100 を超えないように、この値を十分に低く設定する必要があることに注意してください。

  db.serverStatus().connections.available

  本番では現在、これを 40 にしています。

• connectTimeout . その名の通り、接続が中断されるまでにドライバが待つミリ秒の時間です。タイムアウトを長く設定する(15-30秒)と、接続が成功する確率が高くなります。通常、接続の試行が数秒以上かかる場合は、ネットワーク インフラストラクチャが高スループットに対応できていないことになります。

• maxWaitTime . スレッドがコネクションプールで接続が利用可能になるまで待つ時間(ms)で、時間内に起きない場合は例外を発生させます。デフォルトを維持する。

• ソケットタイムアウト . ソケットタイムアウトの標準的な値です。60秒(60000)に設定します。

• threadsAllowedToBlockForConnectionMultiplier（コネクションマルチプライヤー）。 . connectionsPerHost の乗数で、プールが枯渇したときに接続が利用可能になるのを待つために許可されるスレッドの数を表します。これは "com.mongodb.DBPortPool$SemaphoresOut を発生させるための設定です。Out of semaphores to get db connection"例外が発生します。このスレッドキューが threadsAllowedToBlockForConnectionMultiplier 値を超えると、この例外がスローされます。例えば、connectionPerHostが10で、この値が5の場合、前述の例外がスローされる前に最大50スレッドがブロックできます。

  スループットの大きなピークが予想され、一時的に大きなキューを発生させる可能性がある場合、この値を増やします。私たちは、まさにそのような理由から、現時点ではこの値を 1500 にしています。クエリの負荷が常にサーバーを上回っている場合は、それに応じてハードウェアやスケーリングの状況を改善する必要があります。

• 読み込み優先度 . (更新済、2.8+) デフォルトの読み取り優先順位を決定するために使用され、"slaveOk"を置き換えます。ReadPreferenceはクラスファクトリのメソッドで設定します。 最も一般的な設定の詳細については、この投稿の最後にあります。

• w . (更新済み, 2.6+) この値は書き込みの安全性を決定します。この値が-1のとき、書き込みはネットワークやデータベースエラーに関係なく、いかなるエラーも報告しません。WriteConcern.NONEはこのために適切な定義済みのWriteConcernです。w が 0 の場合、ネットワークエラーは書き込みに失敗しますが、mongo のエラーは失敗しません。これは一般に fire and forget 書き込みと呼ばれ、パフォーマンスが一貫性や耐久性よりも重要な場合に使われます。このモードでは WriteConcern.NORMAL を使ってください。

  w を 1 以上に設定すると、書き込みは安全であるとみなされます。安全な書き込みは、書き込みを実行し、書き込みが成功したことを確認するか、成功しなかった場合にエラー値を取得するためにサーバーへの要求によってそれをフォローします (言い換えれば、書き込み後に getLastError() コマンドを送信します)。このgetLastError()コマンドが完了するまで、接続は予約されていることに注意してください。w の値がちょうど 1 の場合、MongoDB は書き込みが成功した (あるいは失敗したと確認できた) ことを保証します。

  レプリカセットの場合は w の値を大きくすると、少なくとも "w" のメンバーに書き込みを送信してから戻るようになります (より正確には、書き込みが "w" のメンバーにレプリケーションされるのを待つようになります)。w に文字列 "majority" を指定すると、レプリカセットのメンバーの大半に書き込みを行うようになります (WriteConcern.MAJORITY) 。パフォーマンス重視 (-1 あるいは 0) かレプリケートライト重視 (>1) でなければ、通常はこれを 1 に設定します。1より大きい値は、書き込みスループットにかなりの影響を与えます。

• fsync . 有効にすると、mongo が各書き込みの後にディスクにフラッシュするように強制する耐久性オプションです。書き込みのバックログに関連した耐久性の問題が発生したことがないので、実運用ではこれを false (デフォルト) にしています。

• j * (NEW 2.7+) *. ブール値を true にすると、MongoDB はジャーナリンググループのコミットが成功するまで戻るのを待ちます。ジャーナリングを有効にしている場合は、これを有効にすることで耐久性を高めることができます。以下を参照ください。 http://www.mongodb.org/display/DOCS/Journaling を参照してください（なぜこのフラグを有効にする必要があるのかも）。

読取プリファレンス ReadPreference クラスを使うと、レプリカセットを使っているときにどの mongod インスタンスにクエリを送るかを設定することができます。以下のオプションが利用可能です。

• ReadPreference.primary() : すべての読み込みは repset のプライマリメンバーにのみ行われます。すべてのクエリで一貫性のある（最も新しく書き込まれた）データを返すことが必要な場合に使用します。これはデフォルトである。

• ReadPreference.primaryPreferred()です。 : すべての読み出しは、可能であれば設定されたプライマリメンバーに行きますが、プライマリノードが利用できない場合はセカンダリメンバーに問い合わせることがあります。このように、プライマリが利用できなくなった場合、読み出しは最終的に一貫したものになります。

• ReadPreference.secondary() : すべての読み込みはセカンダリリセットメンバーに行き、プライマリメンバーは書き込みにのみ使われます。最終的に一貫した読み込みに耐えられる場合のみ、これを使用してください。追加のレプセットメンバーは、レプセットが持つことができる（投票）メンバーの量に制限がありますが、読み取りパフォーマンスをスケールアップするために使用することができます。

• ReadPreference.secondaryPreferred()を使用します。 : すべての読み込みは、セカンダリーリセットメンバーのいずれかが利用可能であれば、それらに移動します。すべてのセカンダリメンバーが利用できなくならない限り、プライマリメンバーが書き込みに独占的に使われます。読み込みのためにプライマリ・メンバーにフォールバックする以外は、これはReadPreference.secondary()と同じである。

• ReadPreference.nearest()です。 : データベースクライアントが利用可能な最も近いレップセットメンバーに読み込みを行います。最終的に一貫した読み込みが許容される場合のみ使用してください。nearest メンバは、クライアントと様々な repset メンバの間のレイテンシーが最も低いメンバです。ビジー状態のメンバーでは最終的にレイテンシが大きくなるため、この は は自動的に読み込みの負荷のバランスを取りますが、私の経験では、メンバーの遅延が比較的一定している場合は、セカンダリ (Preferred) がよりうまくいくようです。

注意: 上記のメソッドにはタグを有効にしたバージョンがあり、代わりにTaggableReadPreferenceのインスタンスを返します。レプリカセットのタグの完全な説明は、こちらでご覧になれます。 レプリカセットタグ