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
設定 ドキュメントの「 システム リソース使用率 」セクションを参照してください。