FAQ： MongoDB によるシャーディング
項目一覧
このドキュメントでは、 シャーディングに関するよくある質問に答えます。 また、マニュアルの「 シャーディング」セクションも参照してください。このセクションでは、次の詳細を含むシャーディング の概要が説明されています。
シャーディングは新しい配置に適していますか?
場合によっては、 ただし、データセットが 1 つのサーバーに収まる場合は、データセットが小さいと利点はほとんど得られないものの、シャーディングとして シャーディングされていない 配置から開始する必要があります。
コレクションをシャーディングした後、別のシャードキーを選択できますか。
シャードキーを変更するためのオプションは、実行している MongoDB のバージョンによって異なります。
MongoDB 5.0 以降では、ドキュメントのシャードキーを変更することでコレクションの再シャーディングが可能です。
既存のシャードキーにサフィックス フィールドを追加することで、シャードキーを調整できます。
ドキュメントがシャード間で分散されないのはなぜですか?
バランサーは、チャンクの分散が一定のしきい値に達すると、シャード間でのデータの分散を開始します。 詳細については、「移行しきい値 」を参照してください。
また、チャンク内のドキュメント数が一定数を超える場合、MongoDB はチャンクを移動できません。 「移行するチャンクあたりの最大ドキュメント数と分割不可/ジャンボチャンク 」を参照してください。
mongosはシャーディングされたシャーディングされたクラスター構成の変更をどのように検出しますか？
インスタンスは、シャーディングされたmongos クラスター のメタデータを保持するコンフィギュレーション データベース のキャッシュを保持します。
mongosは、シャードに リクエストを発行し、メタデータが古くなることを検出して、キャッシュを遅延して更新します。 mongosにキャッシュの再読み込みを強制するには、各 に対してflushRouterConfig mongosコマンドを直接実行します。
writebacklistenログの とは平均ですか。
書込みリスナーは、移行後に長いポーリングを開き、 mongodまたはmongosからの書込みを中継して、間違ったサーバーに移行していないことを確認するプロセスです。 書込み (write) リスナーは、必要に応じて正しいサーバーに書込み (write) を返します。
これらのメッセージはシャーディング インフラストラクチャの重要な部分であり、問題が発生することはありません。
mongosはどのように接続を使用しますか？
各mongosインスタンスは、シャーディングされたクラスターのノードへの接続のプールを維持します。 クライアント リクエストはこれらの接続を一度に 1 つずつ使用します。つまり、リクエストは複数化されず、パイプライン化されません。
クライアントのリクエストが完了すると、 mongosはプールへの接続を返します。 クライアントの数が減少しても、これらのプールは縮小されません。 これにより、多数の接続がオープンされた未使用のmongosが存在する可能性があります。 mongosが使用されなくなった場合は、プロセスを再起動して既存の接続を閉じても安全です。
mongosで使用されるすべての送信接続プールに関連する集計統計を返すには、 mongoshをmongosに接続し、 connPoolStatsコマンドを実行します。
db.adminCommand("connPoolStats");
自己管理型配置の UNIXulimit 設定 ドキュメントの「 システム リソース使用率 」セクションを参照してください。