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