私はmongodbシャードクラスターを持っていますが、シャードキーはハッシュされています。2つのシャードレプリカセットがあります。各レプリカセットには2つのマシンがあります。
別の2つのシャードレプリカセットを追加して実験を行ったところ、リバランスが開始されました。
ただし、しばらくすると、チャンクの移行がかなり遅くなることがわかりました。1.4GBのデータを移動するのに1時間かかります。
それは私を心配させます、それは私が13日間待って500GBのチャンク移行を完了する必要があることを意味します！
私はこのことについては初心者であり、それが遅い、速い、または通常であるかどうかについての神の感触はありません。しかし、それでも、それらの数は私を納得させません。
実験に関する追加メモ：-m3中型awsマシンを使用-他のプロセスは実行せず、チャンク移行のみ-デフォルト設定のmongodbシャーディングインストールで追加の設定なし-シャードキーはオブジェクトID（_id）でハッシュを使用-最大チャンクサイズ64MB
回答:
更新：2018年4月
質問の時点ではこの答えは正しかったが、その後は状況は変わっていない。バージョン3.4以降、並列処理が導入され、最初に参照したチケットはクローズされました。詳細については、この最近の回答で詳細の一部を説明します。残りの回答はそのままにしておきます。これは、一般的な問題/制約に関する優れたリファレンスであり、古いバージョンの誰にとっても有効であるためです。
元の回答
興味がある場合は、M202 Advancedコースのチャンク移行で何が起こるかを詳しく説明します。一般的に言えば、移行がアクティブなシステムで確実に機能するようにハウスキーピングが実行されるため、空のチャンクであっても移行はそれほど高速ではないと言えます（バランシングが発生している場合でもこれらは発生します）。
さらに、クラスター全体で一度に発生する移行は1つだけです-並列処理はありません。したがって、2つの「フル」ノードと2つの「空」ノードがあるという事実にもかかわらず、常に、最大で1つの移行が発生しています（チャンクが最も多いシャードと最も少ないシャードの間）。したがって、2つのシャードを追加しても、速度のバランスをとることはできず、移動する必要のあるチャンクの数が増えるだけです。
移行自体の場合、チャンクのサイズは約30MiBになる可能性があります（データの入力方法によって異なりますが、通常、これはデフォルトの最大チャンクサイズでの平均です）。db.collection.getShardDistribution()その情報の一部を実行できます。チャンクに関するさらに詳しい情報を取得する方法については、こちらの回答をご覧ください。
進行中の他のアクティビティがないため、移行が発生するためには、ターゲットシャード（新しく追加されたシャードの1つ）がソースシャード（元の2つのうちの1つ）から約30MiBのデータを読み取り、構成サーバーを更新する必要があります。完了したら、新しいチャンクの場所を反映します。30MiBのデータの移動は、負荷のない通常のシステムのボトルネックにはなりません。
遅い場合は、いくつかの理由が考えられますが、ビジーでないシステムで最も一般的な理由は次のとおりです。
w:2場合、書き込みの懸念があるかw:majority、デフォルトで使用され、それを満たすために最新のセカンダリが必要です。システムがビジーであった場合、メモリの競合、ロックの競合も通常ここで疑われます。
移行にかかる時間、失敗した場合などの詳細については、次のエントリを参照してくださいconfig.changelog。
// connect to mongos
use config
db.changelog.find()あなたが見たように、そして私がトレーニング/教育をするときに一般的に人々に言うように、あなたが4つのシャードを必要とすることを知っているなら、通常、ランプアップよりも4から始める方が良いです。その場合、シャードの追加には長い時間がかかる可能性があり、最初はゲインではなくリソースのネガティブになることに注意する必要があります（詳細については、シャーディングの落とし穴シリーズのパートIIを参照してください）。
最後に、チャンク移行の並列処理を改善するために機能リクエストを追跡/賛成/コメントするには、SERVER-4355をチェックしてください。